Think Agile - Practice TDD

1,442 views

Published on

Describes the best practices involved in Unit Testing components.

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,442
On SlideShare
0
From Embeds
0
Number of Embeds
216
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Think Agile - Practice TDD

  1. 1.
  2. 2. Unit Testing Good Practices<br />Roy Osherove<br />Chief Architect<br />Typemock<br />DEV204<br />
  3. 3. Team Agile - All rights reserved<br />Real World Agenda<br />Making your tests trustworthy<br />Creating maintainable tests<br />Readable tests – last but not least!<br />
  4. 4. Team Agile - All rights reserved<br />Make Your tests trust worthy<br />Test the right thing<br />Removing or changing tests<br />Assuring code coverage<br />Avoid test logic <br />Make it easy to run<br />
  5. 5. Test the right thing<br />[Test]<br />Public void Sum()<br />{<br /> int result = calculator.Sum(1,2);<br />Assert.AreEqual(4,result, “bad sum”);<br />}<br />Team Agile - All rights reserved<br />
  6. 6. Team Agile - All rights reserved<br />Removing/Changing tests<br />As rule – don’t change or remove. Always add new tests.<br />Unless:<br />It’s for clarity (functionality stays the same)<br />Test is not needed<br />Test is needed to run differently<br />
  7. 7. Team Agile - All rights reserved<br />Assuring code coverage<br />[DEMO]<br />Change production code and see what happens<br />Make params into consts<br />Remove “if” checks – or make into consts<br />If all tests pass - something is missing or something is not needed<br />
  8. 8. Team Agile - All rights reserved<br />Avoid Test Logic<br />No Ifs, SWITCH’s or CASE’s<br />Only Create, configure, act and ASSERT<br />Test logic == test bugs<br />Fail first assures your test is correct as well!<br />
  9. 9. Team Agile - All rights reserved<br />Make it easy to run<br />Integration vs. Unit tests<br />Configuration vs. “ClickOnce”<br />Laziness is key<br />If some tests fail all the time no one listens<br />One package *always* has to work!<br />
  10. 10. Team Agile - All rights reserved<br />Creating maintainable tests<br />Avoid testing private/protected members<br />Re-use test code (Create, Manipulate, Assert)<br />Enforce test isolation<br />Avoid Multiple Asserts<br />
  11. 11. Team Agile - All rights reserved<br />Test only publics<br />Testing a private makes your test more brittle<br />Makes you think about the design and usability of a feature<br />Test-First leads to private members after Refactoring, but they are all tested!<br />But sometimes there’s not choice<br />
  12. 12. Team Agile - All rights reserved<br />Reuse test code<br />[DEMO]<br />Create objects using common methods (factories) <br />[make_XX]<br />Manipulate and configure initial state using common methods <br />[init_XX]<br />Run common tests in common methods <br />[verify_XX]<br />
  13. 13. Team Agile - All rights reserved<br />Enforce test isolation<br />No dependency between tests!<br />Don’t run a test from another test!<br />Run alone <br />or all together <br />in any order<br />Otherwise – leads to nasty “what was that?” bugs<br />
  14. 14. Team Agile - All rights reserved<br />Avoid Multiple Asserts<br />Like having multiple tests<br />But the first the fails – kills the others<br />You won’t get the big picture (some symptoms)<br />Hard to name<br />Can lead to more debugging work<br />
  15. 15. Team Agile - All rights reserved<br />Creating readable tests<br />Naming a unit test<br />Naming variables<br />Separate Assert from action<br />
  16. 16. Team Agile - All rights reserved<br />Naming a unit test<br />Method name<br />State under test<br />Expected behavior/return value<br />Add_LessThanZero_ThrowsException()<br />Another angle:<br />Add_LessThanZero_ThrowsException2()<br />
  17. 17. No Magic Values<br />Assert.AreEqual(1003, calc.Parse(“-1”));<br />IntparseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER);<br />Assert.AreEqual(<br />NEGATIVE_PARSE_RETURN_CODE, <br />parseResult)<br />
  18. 18. Team Agile - All rights reserved<br />Separate Assert from Action<br />Previous example<br />Assert is less cluttered<br />More readable<br />Allows handling the return value if needed<br />It’s all about reability<br />
  19. 19. Summary<br />
  20. 20. Team Agile - All rights reserved<br />Make Your tests trust worthy<br />Test the right thing<br />Removing or changing tests<br />Assuring code coverage<br />Avoid test logic<br />Make it easy to run<br />
  21. 21. Team Agile - All rights reserved<br />Creating maintainable tests<br />Avoid testing private/protected members<br />Re-use test code (Create, Manipulate, Assert)<br />Enforce test isolation<br />Avoid Multiple Asserts<br />
  22. 22. Team Agile - All rights reserved<br />Creating readable tests<br />Naming a unit test<br />Naming variables<br />Separate Assert from action<br />
  23. 23. Team Agile - All rights reserved<br />
  24. 24. www.ArtOfUnitTesting.com<br />Free Chapters<br />www.Typemock.com<br />Typemock Isolator, IntelliTest<br />Resources<br />
  25. 25. Required Slide<br />© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.<br />The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.<br />

×