Think Agile - Practice TDD

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!


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”);}



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


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


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!


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!


Creating maintainable tests

Avoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts


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


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]


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


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


Creating readable tests

Naming a unit testNaming variablesSeparate Assert from action


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)


Separate Assert from Action

Previous example

Assert is less clutteredMore readableAllows handling the return value if neededIt’s all about reability

Summary


Make Your tests trust worthy

Test the right thingRemoving or changing testsAssuring code coverageAvoid test logicMake it easy to run


Creating maintainable tests

Avoid testing private/protected membersRe-use test code (Create, Manipulate, Assert)Enforce test isolationAvoid Multiple Asserts


Creating readable tests

Naming a unit testNaming variablesSeparate Assert from action


Maintainable

Trustworthy

Readable

www.Typemock.com

Typemock Isolator, IntelliTest

Resources

www.ArtOfUnitTesting.com

Free Chapters

http://www.typemock.com/

http://www.artofunittesting.com/

© 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.

Technology

Think Agile - Practice TDD