Upload
vijay-sylvester
View
312
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Describes the best practices for Unit Testing
Citation preview
Unit Testing Good Practices
Roy OsheroveChief ArchitectTypemockDEV204
Team Agile - All rights reserved
Real World Agenda
Making your tests trustworthyCreating maintainable testsReadable tests – last but not least!
Team Agile - All rights reserved
Make Your tests trust worthy
Test the right thingRemoving or changing testsAssuring code coverageAvoid test logic Make it easy to run
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
Team Agile - All rights reserved
Removing/Changing tests
As 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
Team Agile - All rights reserved
Assuring code coverage
[DEMO]Change production code and see what happens
Make params into constsRemove “if” checks – or make into consts
If all tests pass - something is missing or something is not needed
Team Agile - All rights reserved
Avoid Test Logic
No Ifs, SWITCH’s or CASE’sOnly Create, configure, act and ASSERT
Test logic == test bugs
Fail first assures your test is correct as well!
Team Agile - All rights reserved
Make it easy to run
Integration vs. Unit testsConfiguration vs. “ClickOnce”Laziness is key
If some tests fail all the time no one listensOne package *always* has to work!
Team Agile - All rights reserved
Creating maintainable tests
Avoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts
Team Agile - All rights reserved
Test only publics
Testing 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
Team Agile - All rights reserved
Reuse 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]
Team Agile - All rights reserved
Enforce test isolation
No 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
Team Agile - All rights reserved
Avoid Multiple Asserts
Like 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
Team Agile - All rights reserved
Creating readable tests
Naming a unit testNaming variablesSeparate Assert from action
Team Agile - All rights reserved
Naming a unit test
Method nameState under testExpected behavior/return value
Add_LessThanZero_ThrowsException()Another angle:Add_LessThanZero_ThrowsException2()
No Magic Values
Assert.AreEqual(1003, calc.Parse(“-1”));
Int parseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER);
Assert.AreEqual(NEGATIVE_PARSE_RETURN_CODE, parseResult)
Team Agile - All rights reserved
Separate Assert from Action
Previous example
Assert is less clutteredMore readableAllows handling the return value if neededIt’s all about reability
Summary
Team Agile - All rights reserved
Make Your tests trust worthy
Test the right thingRemoving or changing testsAssuring code coverageAvoid test logicMake it easy to run
Team Agile - All rights reserved
Creating maintainable tests
Avoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts
Team Agile - All rights reserved
Creating readable tests
Naming a unit testNaming variablesSeparate Assert from action
Team Agile - All rights reserved
Maintainable
Trustworthy
Readable
www.Typemock.com
Typemock Isolator, IntelliTest
Resources
www.ArtOfUnitTesting.com
Free Chapters
© 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.