Top 10 Mistakes in Unit Testing - Benjamin Day Consulting ...
JUNE 7-10, 2010 | NEW ORLEANS, LA SESSION CODE: DPR204 Top 10 Mistakes in Unit Testing Benjamin Day Architect / Trainer / Coach Benjamin Day Consulting, Inc. 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 http://www.benday.com http://blog.benday.com
[email protected] 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: http://bit.ly/dppXd0
ANNOUNCING Agenda Quick Review: Unit Testing & Test-Driven Development What? Why? My assumptions. Mistakes & Solutions
What is a Unit Test? Piece of code that verifies that another piece of code Test code verifies application code 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) How Do You Do TDD? Brainstorm what you want to do Success cases Failure cases Always start with a failing unit test
The TDD Coding Process From Extreme Programming Explored by William Wake (Addison-Wesley) 1. 2. 3. 4. 5. 6. 7.
8. 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
Why Write Unit Tests? High-quality code 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 The Answer Is Yes. I really do actually code this way. 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 10 Mistakes 1. Forgetting Red-To-Green 2. Poor Naming Conventions 3. Unclear Purpose 4. Code Organization 5. Unit vs. Integration Test Confusion
6. No Code Coverage on Exceptions 7. Giving Up On The User Interface 8. Fixing Bugs Without Unit Tests 9. Useless Code Coverage 10. Stop Mocking Me! Some Bonus Mistakes 11. Giving Up On Legacy Apps 12. Un-testable Architectures 13. Not doing Interface-Driven
Programming 14. Not doing Dependency Injection #1: Forgetting Red-To-Green The Mistake Not starting from a failing automated test Test After instead of Test First What Goes Wrong You dont know when youre 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) #2: Poor Naming Conventions The Mistake Inconsistent naming of test methods
What Goes Wrong Hard to tell what the test is testing The Solution Dont be afraid of long method names Be descriptive Suggestion: ClassName_WhatAreYouTryingToDo_ExpectedResult() Examples:
PersonService_AddValidPerson_Succeeds() PersonService_AddInvalidPerson_ThrowsInvalidOperationException() #3: Unclear Purpose The Mistake Name doesnt 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 Dont do it Refactor Tip: Asserts & Error Messages Assert methods take error message strings
Use them Make them descriptive Easier to debug test failures Use generic assert methods #4: Code Organization The Mistake Unit test code is a mess Coding best practices dont 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
#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 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? The Repository Pattern Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. http://martinfowler.com/eaaCatalog/repository.html Encapsulates the logic of getting things saved and retrieved Repository Pattern & Unit Tests
DEMO #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 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 Dont write your class to use AzureStoragePersonRepository Write the class to code against IPersonRepository Interface-driven programming & Mocks
Interfaces + advertised dependences focused unit tests Only test what you have to If the dependency isnt directly part of the functionality being tested, DONT TEST IT! Send in a mock implementation Mocks let you put exceptions in weird places Im assuming that passing in a mock implementation is easier than the real thing Eliminate that database or service or mainframe dependency in your tests
Mocks vs. Stubs vs. Dummies vs. Fakes http://martinfowler.com/articles/mocksArentStubs.html 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 Test Exception Handling with RhinoMocks
DEMO #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 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! Ive got something for you! QAs Are People, Too. Treat them with respect Theyre on your team You shouldnt need QA to tell you your app doesnt work Use unit tests to minimize the pointless bugs Nothing happened I got an error message. Heres the stack trace. NullReferenceException
QAs should be doing stuff only a human can do QAs should be assigning bugs that have business value Solve the problem by not solving the problem. Dont 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: Its all about automated tests Minimize what you cant automate 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 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 Designing the UI for Testability PersonDetailView.aspx implements
calls Presenter to do work Presenter talks to business objects Use MVP Pattern to Unit Test a User Interface DEMO
#8: Fixing Bugs without Unit Tests The Mistake Youre 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 #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 whats important What is the right amount of coverage 100%? 90%?
75? It depends. 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 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 youve done Just because you can doesnt 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 10 Mistakes 1. Forgetting Red-To-Green 2. Poor Naming Conventions 3. Unclear Purpose
4. Code Organization 5. Unit vs. Integration Test Confusion 6. No Code Coverage on Exceptions 7. Giving Up On The User Interface 8. Fixing Bugs Without Unit Tests 9. Useless Code Coverage 10. Stop Mocking Me! Some Bonus Mistakes 11. Giving Up On Legacy Apps
12. Un-testable Architectures 13. Not doing Interface-Driven Programming 14. Not doing Dependency Injection Thanks! http://www.benday.com http://blog.benday.com 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.
Yeong Foong Choo, Brian L. Evans and *Alan Gatherer. Embedded Signal Processing Laboratory. Wireless Networking & Communications Group. The University of Texas at Austin, Austin, Texas USA ... In the block diagram, the digital processing chains of the IQ samples...
Important determinant of owl occupancy, fitness (Dugger et al. 2005, Franklin et al. 2000, Zabel et al. 2003) Core Area Size Bingham and Noon (1997) recommended using mean core area + 1 SE = 475 acres, based on radio telemetry....
(living space) - This was to become the foreign policy expression of the . Aryan myth. It stated that "inferior nations" next-door to Germany would have to make room for the "superior" Germans. This applied to the 'Slav' peoples -...
What are the Common Core StateStandards? The standards are . . . aligned with college and work expectations. focused and coherent. rigorous in content and application of knowledge through high-order thinking skills. built upon the strengths and lessons of current...
Bush K, Kivlahan DR, McDonell MB, Fihn SD, Bradley KA, Ambulatory Care Quality Improvement Project. The AUDIT alcohol consumption questions (AUDIT-C)—an effective brief screening test for problem drinking. Arch Intern Med. 1998;58:1789-1795.
Chapter 14 Supernatural Beliefs ... Religion Animatism Belief in a generalized, impersonal power over which people have some measure of control. Mana An impersonal supernatural force, inhabiting certain people or things, which is believed to confer power, strength, and success....
History of Measuring Pressure. In 1648, Blaise Pascal(1623-1662) used Torricelli's "barometer" and traveled up and down a mountain in southern France. He discovered that the pressure of the atmosphere increased as he moved down the mountain. Sometime later the SI...
Page * Recommendation to TOSCA TC Facilitate a formal liaison statement from OASIS TOSCA to ETSI NFV proposing ETSI NFV to consider TOSCA's work in there proceedings as required. NFV has already received number of liaison statement from TMF and...
Ready to download the document? Go ahead and hit continue!