Dev204 Osherove

25

description

Describes the best practices for Unit Testing

Transcript of Dev204 Osherove

Page 1: Dev204 Osherove
Page 2: Dev204 Osherove

Unit Testing Good Practices

Roy OsheroveChief ArchitectTypemockDEV204

Page 3: Dev204 Osherove

Team Agile - All rights reserved

Real World Agenda

Making your tests trustworthyCreating maintainable testsReadable tests – last but not least!

Page 4: Dev204 Osherove

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

Page 5: Dev204 Osherove

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

Page 6: Dev204 Osherove

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

Page 7: Dev204 Osherove

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

Page 8: Dev204 Osherove

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!

Page 9: Dev204 Osherove

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!

Page 10: Dev204 Osherove

Team Agile - All rights reserved

Creating maintainable tests

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

Page 11: Dev204 Osherove

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

Page 12: Dev204 Osherove

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]

Page 13: Dev204 Osherove

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

Page 14: Dev204 Osherove

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

Page 15: Dev204 Osherove

Team Agile - All rights reserved

Creating readable tests

Naming a unit testNaming variablesSeparate Assert from action

Page 16: Dev204 Osherove

Team Agile - All rights reserved

Naming a unit test

Method nameState under testExpected behavior/return value

Add_LessThanZero_ThrowsException()Another angle:Add_LessThanZero_ThrowsException2()

Page 17: Dev204 Osherove

No Magic Values

Assert.AreEqual(1003, calc.Parse(“-1”));

Int parseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER);

Assert.AreEqual(NEGATIVE_PARSE_RETURN_CODE, parseResult)

Page 18: Dev204 Osherove

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

Page 19: Dev204 Osherove

Summary

Page 20: Dev204 Osherove

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

Page 21: Dev204 Osherove

Team Agile - All rights reserved

Creating maintainable tests

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

Page 22: Dev204 Osherove

Team Agile - All rights reserved

Creating readable tests

Naming a unit testNaming variablesSeparate Assert from action

Page 23: Dev204 Osherove

Team Agile - All rights reserved

Maintainable

Trustworthy

Readable

Page 24: Dev204 Osherove

www.Typemock.com

Typemock Isolator, IntelliTest

Resources

www.ArtOfUnitTesting.com

Free Chapters

Page 25: Dev204 Osherove

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