Think Agile - Practice TDD
Download as PPTX, PDF1 like521 views
The document discusses best practices for unit testing, including making tests trustworthy by testing the right thing and ensuring code coverage, creating maintainable tests by avoiding test logic and multiple asserts, and writing readable tests through naming conventions and separating asserts from test actions. Key recommendations include not changing tests unless necessary, using code coverage to identify missing tests, avoiding test logic, making tests easy to run, reusing test code, enforcing test isolation, and separating asserts from test code for readability.
![Test the right thing[Test]Public void Sum(){ int result = calculator.Sum(1,2);Assert.AreEqual(4,result, “bad sum”);}Team Agile - All rights reserved](https://image.slidesharecdn.com/cdocumentsandsettingsvsylvestdesktopscorisdeliverydev204osherove-100117071039-phpapp02/85/Think-Agile-Practice-TDD-5-320.jpg)
![Team Agile - All rights reservedAssuring code coverage[DEMO]Change production code and see what happensMake params into constsRemove “if” checks – or make into constsIf all tests pass - something is missing or something is not needed](https://image.slidesharecdn.com/cdocumentsandsettingsvsylvestdesktopscorisdeliverydev204osherove-100117071039-phpapp02/85/Think-Agile-Practice-TDD-7-320.jpg)
![Team Agile - All rights reservedReuse test code[DEMO]Create objects using common methods (factories) [make_XX]Manipulate and configure initial state using common methods [init_XX]Run common tests in common methods [verify_XX]](https://image.slidesharecdn.com/cdocumentsandsettingsvsylvestdesktopscorisdeliverydev204osherove-100117071039-phpapp02/85/Think-Agile-Practice-TDD-12-320.jpg)
Think Agile - Practice TDD
- 2. Unit Testing Good PracticesRoy OsheroveChief ArchitectTypemockDEV204
- 3. Team Agile - All rights reservedReal World AgendaMaking your tests trustworthyCreating maintainable testsReadable tests – last but not least!
- 4. Team Agile - All rights reservedMake Your tests trust worthyTest the right thingRemoving or changing testsAssuring code coverageAvoid test logic Make it easy to run
- 5. Test the right thing[Test]Public void Sum(){ int result = calculator.Sum(1,2);Assert.AreEqual(4,result, “bad sum”);}Team Agile - All rights reserved
- 6. Team Agile - All rights reservedRemoving/Changing testsAs rule – don’t change or remove. Always add new tests.Unless:It’s for clarity (functionality stays the same)Test is not neededTest is needed to run differently
- 7. Team Agile - All rights reservedAssuring code coverage[DEMO]Change production code and see what happensMake params into constsRemove “if” checks – or make into constsIf all tests pass - something is missing or something is not needed
- 8. Team Agile - All rights reservedAvoid Test LogicNo Ifs, SWITCH’s or CASE’sOnly Create, configure, act and ASSERTTest logic == test bugsFail first assures your test is correct as well!
- 9. Team Agile - All rights reservedMake it easy to runIntegration vs. Unit testsConfiguration vs. “ClickOnce”Laziness is keyIf some tests fail all the time no one listensOne package *always* has to work!
- 10. Team Agile - All rights reservedCreating maintainable testsAvoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts
- 11. Team Agile - All rights reservedTest only publicsTesting a private makes your test more brittleMakes you think about the design and usability of a featureTest-First leads to private members after Refactoring, but they are all tested!But sometimes there’s not choice
- 12. Team Agile - All rights reservedReuse test code[DEMO]Create objects using common methods (factories) [make_XX]Manipulate and configure initial state using common methods [init_XX]Run common tests in common methods [verify_XX]
- 13. Team Agile - All rights reservedEnforce test isolationNo dependency between tests!Don’t run a test from another test!Run alone or all together in any orderOtherwise – leads to nasty “what was that?” bugs
- 14. Team Agile - All rights reservedAvoid Multiple AssertsLike having multiple testsBut the first the fails – kills the othersYou won’t get the big picture (some symptoms)Hard to nameCan lead to more debugging work
- 15. Team Agile - All rights reservedCreating readable testsNaming a unit testNaming variablesSeparate Assert from action
- 16. Team Agile - All rights reservedNaming a unit testMethod nameState under testExpected behavior/return valueAdd_LessThanZero_ThrowsException()Another angle:Add_LessThanZero_ThrowsException2()
- 17. No Magic ValuesAssert.AreEqual(1003, calc.Parse(“-1”));IntparseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER);Assert.AreEqual(NEGATIVE_PARSE_RETURN_CODE, parseResult)
- 18. Team Agile - All rights reservedSeparate Assert from ActionPrevious exampleAssert is less clutteredMore readableAllows handling the return value if neededIt’s all about reability
- 19. Summary
- 20. Team Agile - All rights reservedMake Your tests trust worthyTest the right thingRemoving or changing testsAssuring code coverageAvoid test logicMake it easy to run
- 21. Team Agile - All rights reservedCreating maintainable testsAvoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts
- 22. Team Agile - All rights reservedCreating readable testsNaming a unit testNaming variablesSeparate Assert from action
- 23. Team Agile - All rights reserved
- 24. www.ArtOfUnitTesting.comFree Chapterswww.Typemock.comTypemock Isolator, IntelliTestResources
- 25. Required Slide© 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.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.