1. Top 10 Mistakes in Unit Testing
Tech Ed North America 2010
6/26/2018 6:06 AM
Required Slide
SESSION CODE: DPR204
Top 10 Mistakes in Unit Testing
Benjamin Day
Architect / Trainer / Coach
Benjamin Day Consulting, Inc.
© 2010 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.

2. Who am I? Consultant, Trainer MVP for Visual Studio ALM
Development, Project Coaching, Training
TFS, Scrum, TDD, Silverlight, WCF, Windows Azure
Professional Scrum Developer Certified Trainer
Microsoft VSTS Customer Advisory Council
Leader of Beantown .NET User Group

3. Professional Scrum Developer Program
Tech Ed North America 2010
6/26/2018 6:06 AM
Professional Scrum Developer Program
An innovate program for developers from Microsoft and the founders of Scrum
Learn how to use modern engineering practices to develop an increment of complete, potentially shippable functionality using Visual Studio 2010, ALM, and the Scrum framework
Training course, assessment, and certification available
Visit MSDN for more details:
ANNOUNCING
© 2010 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.

4. Agenda Quick Review: Unit Testing & Test-Driven Development
What?
Why?
My assumptions.
Mistakes & Solutions

5. What is a Unit Test?
Piece of code that verifies that another piece of code
Test code verifies application code

6. What is Test-Driven Development (TDD)?
Practice of developing code so that you always have proof that the code is working
Mindset
“Never write a single line of code unless you have a failing automated test.” -Kent Beck (“Test-Driven Development”, Addison-Wesley)

7. How Do You Do TDD? Brainstorm what you want to do
Success cases
Failure cases
Always start with a failing unit test

8. The TDD Coding Process
From “Extreme Programming Explored” by William Wake (Addison-Wesley)
Write the test code
Compile the test code  Fails
Implement just enough to compile
Run the test  Fails
Implement enough code to make the test pass
Run the test  Pass
Refactor for clarity and to eliminate duplication
Repeat

9. Why Write Unit Tests? High-quality code Professional Responsibility
Fewer bugs
Clean design
Clean code
Professional Responsibility
Proof that your code works
Notification when your code is broken
Quality focus throughout the development cycle
Side Effects
Code is easier to maintain, refactor
Self-documenting

10. The Answer Is ‘Yes’.
I really do actually code this way.

11. Why Testing Can Sometimes Fail
Doing it Wrong
Process Problems
Style Problems
Tests take too long to write
Tedious
Complex
Poor Organization
Maintenance problems
Overkill
Fuzzy Thinking

12. 10 Mistakes Forgetting Red-To-Green Poor Naming Conventions
Unclear Purpose
Code Organization
Unit vs. Integration Test Confusion
No Code Coverage on Exceptions
Giving Up On The User Interface
Fixing Bugs Without Unit Tests
Useless Code Coverage
Stop Mocking Me!

13. Some Bonus Mistakes Giving Up On Legacy Apps Un-testable Architectures
Not doing Interface-Driven Programming
Not doing Dependency Injection

14. #1: Forgetting Red-To-Green
The Mistake
Not starting from a failing automated test
Test After instead of Test First
What Goes Wrong
You don’t know when you’re done
You know how to write the code but not how to test the code
Low code coverage
Low quality code
Solution
Test-Driven Development (TDD)

15. #2: Poor Naming Conventions
The Mistake
Inconsistent naming of test methods
What Goes Wrong
Hard to tell what the test is testing
The Solution
Don’t be afraid of long method names
Be descriptive
Suggestion: ClassName_WhatAreYouTryingToDo_ExpectedResult()
Examples:
PersonService_AddValidPerson_Succeeds()
PersonService_AddInvalidPerson_ThrowsInvalidOperationException()

16. #3: Unclear Purpose The Mistake What Goes Wrong The Solution
Name doesn’t reflect what the test does
Test tries to do too much
What Goes Wrong
Hard to tell what the test is testing
Complex code  difficulty debugging
Maintenance issues
Is it really a “unit” test?
The Solution
Don’t do it
Refactor

17. Tip: Asserts & Error Messages
Assert methods take error message strings
Use them
Make them descriptive
Easier to debug test failures
Use “generic” assert methods

18. #4: Code Organization The Mistake What Goes Wrong The Solution
Unit test code is a mess
Coding best practices don’t apply to unit test code
What Goes Wrong
Code is a mess
Maintenance problems
Duplicate code
The Solution
Code reviews
Require the same quality from your unit test code as with your application code

19. #5: Unit vs. Integration Test Confusion
The Mistake
Unit tests require a database, WCF service, etc
Trying to test too much at once
What Goes Wrong
Lots of dependencies
Makes testing difficult
Test run slowly
The Solution
Separate your Unit tests from the Integration tests
Interface-driven programming
Repository Pattern

20. Avoid End-to-End Integration Tests
Does a good test…
…really have to write all the way to the database?
…really have to have a running WCF service on the other end of that call?
…really need to make a call to the mainframe?

21. The Repository Pattern
“Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.”
Encapsulates the logic of getting things saved and retrieved

22. Repository Pattern & Unit Tests
DEMO

23. #6: No Code Coverage On Exceptions
The Mistake
Forgetting to test exceptions
Doing a poor job of testing exceptions
What Goes Wrong
Low code coverage metrics
Lots of bugs from production
The Solution
Interface-driven programming
Dependency Injection
Mocking Frameworks

24. Interface-driven programming & Mocks
Unit tests should be focused, targeted
Should only attempt to test small amounts of functionality
Objects should “advertise” their dependencies
If your class needs an instance of IPersonRepository, it should advertise it on the constructor
Objects should depend on interfaces not concrete types
Don’t write your class to use AzureStoragePersonRepository
Write the class to code against IPersonRepository

25. Interface-driven programming & Mocks
Interfaces + “advertised” dependences  focused unit tests
Only test what you have to
If the dependency isn’t directly part of the functionality being tested, DON’T TEST IT!
Send in a “mock” implementation
Mocks let you put exceptions in weird places
I’m assuming that passing in a “mock” implementation is easier than the real thing
Eliminate that database or service or mainframe dependency in your tests

26. Mocks vs. Stubs vs. Dummies vs. Fakes
Dummy = passed but not used
Fake = “shortcut” implementation
Stub = Only pretends to work, returns pre-defined answer
Mock = Used to test expectations, requires verification at the end of test

27. Test Exception Handling with RhinoMocks
DEMO

28. #7: Giving Up On The User Interface
The Mistake
Assuming user interface not testable
Leave the UI testing to the QA Team
What Goes Wrong
Wasted QA cycles
All the really important stuff goes untested
Lots of bugs from production
“Code Behinds” have lots of logic in them
The Solution
User interface design patterns

29. Yes, I agree. User Interfaces are a challenge to test
You have to simulate a user doing “stuff”
Who better to test that than a human being
“Hey! QA guy! I’ve got something for you!”

30. QA’s Are People, Too. Treat them with respect They’re on your team
You shouldn’t need QA to tell you your app doesn’t work
Use unit tests to minimize the pointless bugs
“Nothing happened”
“I got an error message. Here’s the stack trace.”
NullReferenceException
QA’s should be doing stuff only a human can do
QA’s should be assigning bugs that have business value

31. Solve the problem by not solving the problem.
Don’t try to test the UI
Design for testability
Separate the user interface from the presentation code
Keep as much logic as possible out of the UI tier
Remember: It’s all about automated tests
Minimize what you can’t automate

32. Presentation Design Patterns
Models the user interface interaction with the “business” tier
Model View Presenter (MVP)
Windows Forms
ASP.NET WebForms
Model View Controller (MVC)
ASP.NET MVC Framework
Model View ViewModel (MVVM)
Silverlight
WPF

33. The Model View Presenter Pattern
Variation of Model View Controller (MVC)
Works great for anything that does postback to a code behind
Model = Domain Model (aka. Business Object)
View = abstraction of a user interface
C# or VB.NET interface
Controller = Presentation logic
Unit tests will focus on the Controller

34. Designing the UI for Testability
PersonDetailView.aspx
implements
calls Presenter to do work
Presenter talks to business objects

35. Use MVP Pattern to Unit Test a User Interface
DEMO

36. #8: Fixing Bugs without Unit Tests
The Mistake
You’re assigned a bug and you just fix it without a unit test.
What Goes Wrong
Did you really fix the bug?
Did you really re-create the bug?
Missed opportunities
No long-term, automated regression tests
Missed code coverage
The Solution
Always go from Red-to-Green
Start with a failing test THEN fix the bug

37. #9: Useless Code Coverage
The Mistake
You become obsessed with 100% code coverage
What Goes Wrong
Lots of extra time
False sense of security
The Solution
Take a deep breath
Think about what’s important

38. What is the right amount of coverage
100%?
90%?
75?
It depends.

39. 100% Code Coverage
"Just because you have 100% code coverage doesn't mean that your code works. It only means that you've executed every line." - Scott Hanselman (Hanselminutes interview with Scott Bellware)

40. #10: Stop Mocking Me! The Mistake What Goes Wrong The Solution
You go nuts with mocks
What Goes Wrong
Test code gets complex & hard to understand
Mocking everything but testing nothing
False sense of security
Huge dependencies on the mocking framework
Dependencies on internal implementation of a class
The Solution
Put down that mocking framework. Back away slowly.
Think about what you’ve done

41. Just because you can doesn’t mean you should.
Lots of dynamic mock code
Could it be replaced with a custom mock object?
Too much checking of internal behaviors
MethodA() gets called and return X then calls MethodB() and gets back Y then MethodC() is called and gets back Z etc etc etc
Implementation is encapsulated for a reason
Keep it loose

42. 10 Mistakes Forgetting Red-To-Green Poor Naming Conventions
Unclear Purpose
Code Organization
Unit vs. Integration Test Confusion
No Code Coverage on Exceptions
Giving Up On The User Interface
Fixing Bugs Without Unit Tests
Useless Code Coverage
Stop Mocking Me!

43. Some Bonus Mistakes Giving Up On Legacy Apps Un-testable Architectures
Not doing Interface-Driven Programming
Not doing Dependency Injection

44. Thanks!

45. Resources Learning Required Slide www.microsoft.com/teched
Tech Ed North America 2010
6/26/2018 6:06 AM
Required Slide
Resources
Learning
Sessions On-Demand & Community
Microsoft Certification & Training Resources
Resources for IT Professionals
Resources for Developers
© 2010 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.

46. Complete an evaluation on CommNet and enter to win!
Tech Ed North America 2010
6/26/2018 6:06 AM
Required Slide
Complete an evaluation on CommNet and enter to win!
© 2010 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.

47. Sign up for Tech·Ed 2011 and save $500 starting June 8 – June 31st
You can also register at the North America 2011 kiosk located at registration Join us in Atlanta next year

48. Tech Ed North America 2010 6/26/2018 6:06 AM
© 2010 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.
© 2010 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.

49. Required Slide Tech Ed North America 2010 6/26/2018 6:06 AM
© 2010 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.