Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tdd Ugialtnet Jan2010

660 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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 />

×