C16_Effective_Unit_Testing.ppt
Upcoming SlideShare
Loading in...5
×
 

C16_Effective_Unit_Testing.ppt

on

  • 1,538 views

 

Statistics

Views

Total Views
1,538
Views on SlideShare
1,538
Embed Views
0

Actions

Likes
0
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Demo NUnit, NUnitAddin, Resharper Templates, etc. Talk about VSTS

C16_Effective_Unit_Testing.ppt Presentation Transcript

  • 1. Effective Unit Testing with NUnit Win-Dev 2004 Friday, October 29, 2004 Peter Provost Software Design Engineer patterns & practices Microsoft Corporation
  • 2. Agenda
    • What is Unit Testing?
    • Typical Unit Testing Problems
    • Best Practices for Effective Unit Testing
    • Tools Demo
    • Q & A
  • 3. What is Unit Testing?
  • 4. A Definition
    • Unit Testing is code that…
      • Is written by developers, for developers.
      • Exercises a small, specific area of functionality.
      • Helps “prove” that a piece of code does what the developer expects it to do.
  • 5. What Unit Testing Is Not
    • Acceptance Testing (aka Functional Testing)
    • Performance Testing
    • Scalability Testing
  • 6. Marick’s Four Quadrants of Testing Source: Brian Marick – http://testing.com/
  • 7. Why Unit Test
    • It will make your life easier
    • Better code
    • Better designs
    • Code is easier to maintain later
    • Confidence when you code
  • 8. Common Excuses
    • I’m not a tester!
    • It takes too much time.
    • It takes too long to run the tests.
    • I don’t know how to test it.
    • I don’t really know what it is supposed to do, so I can’t test it.
    • But it compiles! It doesn’t need tests.
  • 9. Typical Unit Testing Problems
  • 10. Testing Is Monotonous and Boring
    • Often indicates bad tooling or bad techniques
    • Unit testing should…
      • Be easy to do
      • Provide rapid feedback
  • 11. Poor Test Coverage
    • Often happens when tests not written first
    • Hard to retrofit later
    • Test coverage is orthogonal to test quality
  • 12. Purpose of Tests is Misunderstood
    • Remember why we do unit testing
    • Easy to get distracted by irrelevant things
    • What is the scope of the test?
  • 13. Informal Testing Process
    • How does your team do unit testing?
      • Test-first
      • Intuitive “poking and prodding” style testing
      • Smoke testing
      • Whatever the developer wants
  • 14. Inconsistent Testing
    • Are tests required before check in?
    • How is it enforced?
  • 15. Low Test Quality
    • Single biggest problem in unit testing today
    • Testing requires a special mindset
    • Tools only solve half the problem
  • 16. Code Not Designed for Test
    • Often the cause of low test quality
    • Hard to design testable code
    • However, testable code often is better designed
  • 17. Tests Not Maintained
    • So you’ve shipped your code and someone finds a bug…
    • Do you fix the tests? Or just fix the bug?
    • What about the rest of the team?
  • 18. Best Practices for Effective Unit Testing
  • 19. Automate Your Tests
    • If it is hard to run tests, you won’t do it
    • Manual (aka scripted) tests make regression testing very hard
  • 20. Use Good Tools
    • The tools should make it…
      • Easy to write tests
      • Easy to organize your tests
      • Easy to run tests (all, some, one)
    • They should provide…
      • Quick feedback of pass/fail
      • Details on the fail conditions
  • 21. Use Good Tools
    • Testing Focused Tools
    • NUnit
    • csUnit
    • MbUnit
    • Test Driven .NET (aka NUnitAddin)
    • NMock
    • DotNetMock
    • Supporting Tools
    • NAnt
    • CodeRush
    • Resharper
    • CodeSmith
    • And of course…
    • Visual Studio .NET
  • 22. Tools Demo
  • 23. Get a Mentor
    • Testing is as much an art as a science
    • Learning to write good tests is hard
    • Some people are naturally good at it and some aren’t
  • 24. Use a Test List
    • Start your development activities by writing down a list of things you want to test
    • You will often think of a test while writing another one. When you do, add it to the list.
    • Review your list frequently
  • 25. Write Tests First
    • Test-driven development (TDD) is a proven way of improving quality*
    • TDD’s main objective is not testing software! (this is a side effect)
    • TDD’s main objective is to aid programmers and customers during the development process with unambiguous requirements.
    • Code is written with testing as a primary motivation. In short, the code is testable.
    • * - http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf
  • 26. What to Test
    • The “did we get what we expected” test isn’t always good enough
    • Ask yourself the question…
      • “If the code ran correctly, how would I know?”
  • 27. What to Test - Testing Heuristics
    • Test at the boundaries
    • Test every error message
    • Test different configurations
    • Run tests that are annoying to setup
    • Avoid redundant tests
      • Source: Lessons Learned in Software Testing, by Cem Kaner, James Bach, Brett Pettichord
  • 28. What to Test – BICEP
      • B Are the boundary conditions correct?
      • I Can you check inverse relationships?
      • C Can you cross check using other means?
      • E Can you force an error condition to happen?
      • P Are the performance characteristics acceptable?
    • Source: Pragmatic Unit Testing in C# with NUnit by Andrew Hunt and Dave Thomas
  • 29. Test Structure
    • William Wake’s 3-A Pattern
      • Arrange
      • Act
      • Assert
  • 30. Designing for Test
    • One simple question to help you write good code…
    • “ How am I going to test this?”
    • If you don’t know the answer, then you probably need to reconsider your design.
  • 31. Stubs and Mocks
    • Stub Defined
    • “ A portion is a portion of code that is inserted at runtime in place of real code, in order to isolate calling code from the real implementation. The intent is to replace a complex behavior with a simpler one that allows independent testing of some portion of real code.”
    • Mock Objects Defined
    • “ A mock object is an object created to stand in for an object that your code will be collaborating with. Your code can call methods on the mock object, will deliver results as set up by your tests.”
    • Source: JUnit in Action, by Vincent Massol
  • 32. When are stubs appropriate?
    • Objects that are expensive to create to manipulate
    • At the edges of a system, or around complex clusters of objects
    • Course-grained testing, integration testing
  • 33. Stub Downsides
    • A Complex system might require a complex stub
    • Hard to write in a verifiable way
    • Difficult to maintain
  • 34. When are mocks appropriate?
    • Real object has non-deterministic behavior
    • Real object is difficult to set up
    • Real object has behavior that is difficult to cause
    • Real object is slow
    • Source:http://c2.com/cgi/wiki?MockObjects
  • 35. Mock Downsides
    • Code complexity of being able to switch between real and mock implementations
    • Maintaining the mock
  • 36. Properties of Good Tests
    • Automatic Tests need to be run checked automatically
    • Thorough Test everything that could possibly break
    • Repeatable Tests should produce the same results each time they are run
    • Independent A test should exercise only one thing at a time
    • Professional Tests are code too! Write them professionally.
    • Source: Pragmatic Unit Testing in C# with NUnit by Andrew Hunt and Dave Thomas
  • 37. Test Organization Options
    • Tests in the VS Project being tested
      • Best for experiments, spikes, etc.
    • Tests in a separate VS Project
      • Most commonly used arrangement
      • Tests are not part of distribution
    • Tests in a separate VS Solution
      • The usual reference issues, but possible
  • 38. Recommended Test Organization
    • Tests in a separate project/assembly
    • Naming conventions
        • If you are testing the class:
        • Foo.Bar.Baz
        • Then you should name your tests
        • Foo.Bar.Tests.BazTests
    • Note the namespace and test class name!
  • 39. When to Run Tests
    • When you write a new method…
      • …compile and run local unit tests
    • When you fix a bug…
      • …run the test that illustrates that bug.
    • Any successful compile…
      • …run local unit tests.
    • Before you check in…
      • …run all tests.
    • Continuously…
      • ...check out and build the project from scratch including all unit tests.
  • 40. Do not check in code that…
    • Is incomplete (e.g. missing dependencies)
    • Doesn’t compile
    • Compiles but breaks other code
    • Doesn’t have unit tests
    • Has failing unit tests
    • Passes its tests but causes other tests to fail.
  • 41. Additional Resources
  • 42. Web Sites
    • http://www.testdriven.com
    • http://www.xprogramming.com
    • http://workspaces.gotdotnet.com/tdd
  • 43. Weblogs
    • Peter Provost
      • http://www.peterprovost.org
    • Jim Newkirk
      • http://weblogs.asp.net/jamesnewkirk
    • Brian Button
      • http://dotnetjunkies.com/WebLog/oneagilecoder/
    • Martin Fowler
      • http://www.martinfowler.com/bliki/
    • Darrell Norton
      • http://dotnetjunkies.com/WebLog/darrell.norton/
  • 44. Mailing Lists
    • Yahoo Group: testdrivendevelopment
    • Yahoo Group: agiledotnet
    • Yahoo Group: extremeprogramming
  • 45. Books
    • Test-Driven Development in Microsoft .NET – James Newkirk and Alexei Vorontsov
    • Pragmatic Unit Testing in C# with NUnit – Andrew Hunt and David Thomas
    • Test-Driven Development, by Example – Kent Beck
    • Refactoring to Patterns – Joshua Kerievsky
    • Lessons Learned in Software Testing – Cem Kaner, James Bach, and Brett Pettichord
  • 46. Questions? Comments
    • Peter Provost
    • Software Design Engineer
    • patterns & practices
    • Microsoft Corporation
    • E-mail: peterpr@microsoft.com
    • Weblog: http://www.peterprovost.org/
    • NOTE : Updated slides available at http://www.peterprovost.org/Files/C16_Effective_Unit_Testing.ppt