Tdd Ugialtnet Jan2010

574 views
546 views

Published on

Test Driven Development
Thousands of Red-Green-Refactor after…

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
574
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tdd Ugialtnet Jan2010

  1. 1. Test Driven Development<br />Thousands of Red-Green-Refactor after…<br />UGIALT.NET – Milano 23-01-2010<br />Omid Ehsani<br />Senior Consultant & Solution Architect<br />omid.ehsani@lightcode.net<br />
  2. 2. Automated Testing<br />Good Automated Tests should be:<br />Isolated, Fast, Repeatable, Maintainable, …<br />How can we achieve those goals?<br />Do the same rules ensure good Automated Test Suites (ATS)?<br />Any difference for one-man-band or team?<br />
  3. 3. Working in Team<br />Consider typical scenarios<br />Rebuilding development machines<br />Introducing new developers<br />Introducing Continuous Integration servers<br />Make building and running ATS easy<br />Put under source control build requirements<br />Minimize test dependencies with external configuration<br />Make tests running fast<br />
  4. 4. ATS Organization<br />Include tests in the same Visual Studio solution (but in separate projects)<br />Separate different test types (mostly Unit Tests from Integration Tests)<br />Human factor: how frequently developers run automated tests?<br />Create a safe green zone<br />
  5. 5. Finding tests<br />Where are my project tests?<br />Where are my class tests?<br />Where are my method tests?<br />Map tests to your system under test (SUT)<br />Use naming and namespaces to define project/assembly tests<br />Unit testing<br />One test class per SUT class<br />One or more test methods per SUT method<br />Integration / user acceptance testing<br />One test class per feature<br />ATS Mapping<br />
  6. 6. Write ReadableTests<br />Naming<br />Naming unit tests<br />Naming variables<br />Meaningful asserts<br />Explicit test sections (AAA, SEV, …)<br />Test method in a screen<br />Setting up and tearing down<br />Explicit Data<br />
  7. 7. Writing Trustworthy Tests<br />When to remove or change tests<br />Production or test bugs<br />Semantics or API changes or Refactoring <br />Duplicated tests<br />Avoid logic in tests<br />Don’t use loops and conditionals<br />Harder to read, likely to have bugs, difficult to name<br />Testing only one thing<br />Improper naming, failing asserts<br />
  8. 8. Write Maintainable Tests<br />Testing private o protected methods<br />Making methods public<br />Extracting methods to new classes<br />Making methods internal<br />Removing duplication<br />Using helper methods<br />Using [SetUp]<br />Test class inheritance<br />Use domain object names in comments and assertion messages<br />Simplify refactoring/renaming with smart tools like ReSharper.<br />
  9. 9. Your Application’s Test API<br />Test utilities and helpers<br />Make test API known to developers<br />Test class inheritance patterns<br />DRY (Don’t Repeat Yourself)<br />Creating testing guidance for developers<br />
  10. 10. Test class inheritance patterns<br />Abstract test infrastructure class<br />Base class containing essential common infrastructure. <br />Common setup and teardown.<br />Template test class<br />Base class containing abstract test methods that derived classes must implement.<br />Multiple implementations of same interface.<br />Abstract test driver class<br />Base class containing test method implementations inherited by all deriving classes.<br />Testing class hierarchies.<br />
  11. 11. Assertions Antipatterns<br />The Giant: Too many assertions in a test (God Object?)<br />Multiple aspects of same object (state check, identity)<br />The Dodger: Lots of minor asserts checking side-effects but none testing core desired behavior (database testing)<br />The Free Ride: Instead of writing a new test case assertions are added to an existing one<br />Overspecifying tests<br />The Inspector: Specifying purely internal behavior<br />Using mocks instead of stubs<br />The Nitpicker: Assuming exact and complete match when not needed<br />
  12. 12. Setup Antipatterns<br />Initialize objects in [SetUp] used only in some of tests<br />Excessive Setup: setup “noise” make test hard to read<br />Fakes and mocks initialized in [SetUp]<br />The Mockery: too many mocks and stubs move the test focus on fake data instead of SUT<br />
  13. 13. Isolation Antipatterns<br />Generous Leftovers: constrainted test order<br />The Peeping Tom: Shared state corruption<br />Hidden test call<br />The Local Hero: Test running only on development box and failing elsewhere<br />Have your Continuous Integration up and running<br />
  14. 14. Other Antipatterns<br />The Loudmouth: test cluttering console with diagnostic messages.<br />The Secret Catcher: Apparently no asserts, test success relying on framework exception catching<br />The Enumerator: Test case method names like test1, test2, test3,…<br />Success Against All Odds: test written as pass first rather than fail first<br />
  15. 15. Happy TDD!<br /><ul><li>Questions & Answers
  16. 16. Resources</li></ul>Roy Osherove<br />The art of unit testing<br />Kent Beck<br />Test-Driven Development by example<br />omid.ehsani@lightcode.net<br />

×