Your SlideShare is downloading. ×
Think Agile - Practice TDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Think Agile - Practice TDD

1,228

Published on

Describes the best practices involved in Unit Testing components.

Describes the best practices involved in Unit Testing components.

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

  • Be the first to like this

No Downloads
Views
Total Views
1,228
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.
  • 2. Unit Testing Good Practices
    Roy Osherove
    Chief Architect
    Typemock
    DEV204
  • 3. Team Agile - All rights reserved
    Real World Agenda
    Making your tests trustworthy
    Creating maintainable tests
    Readable tests – last but not least!
  • 4. Team Agile - All rights reserved
    Make Your tests trust worthy
    Test the right thing
    Removing or changing tests
    Assuring code coverage
    Avoid 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 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 needed
    Test is needed to run differently
  • 7. Team Agile - All rights reserved
    Assuring code coverage
    [DEMO]
    Change production code and see what happens
    Make params into consts
    Remove “if” checks – or make into consts
    If all tests pass - something is missing or something is not needed
  • 8. Team Agile - All rights reserved
    Avoid Test Logic
    No Ifs, SWITCH’s or CASE’s
    Only Create, configure, act and ASSERT
    Test logic == test bugs
    Fail first assures your test is correct as well!
  • 9. Team Agile - All rights reserved
    Make it easy to run
    Integration vs. Unit tests
    Configuration vs. “ClickOnce”
    Laziness is key
    If some tests fail all the time no one listens
    One package *always* has to work!
  • 10. Team Agile - All rights reserved
    Creating maintainable tests
    Avoid testing private/protected members
    Re-use test code (Create, Manipulate, Assert)
    Enforce test isolation
    Avoid Multiple Asserts
  • 11. Team Agile - All rights reserved
    Test only publics
    Testing a private makes your test more brittle
    Makes you think about the design and usability of a feature
    Test-First leads to private members after Refactoring, but they are all tested!
    But sometimes there’s not choice
  • 12. 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]
  • 13. 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 order
    Otherwise – leads to nasty “what was that?” bugs
  • 14. Team Agile - All rights reserved
    Avoid Multiple Asserts
    Like having multiple tests
    But the first the fails – kills the others
    You won’t get the big picture (some symptoms)
    Hard to name
    Can lead to more debugging work
  • 15. Team Agile - All rights reserved
    Creating readable tests
    Naming a unit test
    Naming variables
    Separate Assert from action
  • 16. Team Agile - All rights reserved
    Naming a unit test
    Method name
    State under test
    Expected behavior/return value
    Add_LessThanZero_ThrowsException()
    Another angle:
    Add_LessThanZero_ThrowsException2()
  • 17. No Magic Values
    Assert.AreEqual(1003, calc.Parse(“-1”));
    IntparseResult = calc.Parse(NEGATIVE_ILLEGAL_NUMBER);
    Assert.AreEqual(
    NEGATIVE_PARSE_RETURN_CODE,
    parseResult)
  • 18. Team Agile - All rights reserved
    Separate Assert from Action
    Previous example
    Assert is less cluttered
    More readable
    Allows handling the return value if needed
    It’s all about reability
  • 19. Summary
  • 20. Team Agile - All rights reserved
    Make Your tests trust worthy
    Test the right thing
    Removing or changing tests
    Assuring code coverage
    Avoid test logic
    Make it easy to run
  • 21. Team Agile - All rights reserved
    Creating maintainable tests
    Avoid testing private/protected members
    Re-use test code (Create, Manipulate, Assert)
    Enforce test isolation
    Avoid Multiple Asserts
  • 22. Team Agile - All rights reserved
    Creating readable tests
    Naming a unit test
    Naming variables
    Separate Assert from action
  • 23. Team Agile - All rights reserved
  • 24. www.ArtOfUnitTesting.com
    Free Chapters
    www.Typemock.com
    Typemock Isolator, IntelliTest
    Resources
  • 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.

×