Guidelines for Better Unit Tests

Posted by Mark Levison on Jul 24, 2009

Community

Agile

Topics

Unit Testing

Tags

Testing ,

Refactoring

Jimmy Bogard, wrote an article: “Getting value out of your unit tests”, where he gives three rules:

1. “Test names should describe the what and the why, from the user’s perspective” – the idea is that a developer should be able to read the name and understand what the intended behavior is.
2. “Tests are code too, give them some love” – production code isn't the only place that you should do your refactoring. Readable tests are easier to maintain and easier for next person to understand. “I hate, hate long, complex tests.  If a test has 30 lines of setup, please put that behind a creation method.  A long test just irritates and leaves the developer cross-eyed.  If I don’t have long methods in production code, why would I allow this in our test code?”
3. “Don’t settle on one fixture pattern/organizational style” – Sometimes the standard pattern of one class, one test fixture doesn’t work.

Lior Friedman added: “Rule #0 - Test external behavior and not internal structure.” Or, test the expectations for a class not its current structure.

Ravichandran Jv added his own rules:

1. One Assert per test (where possible). 
2. If there are any "if else" inside a test, move the branches to individual test methods. 
3. Methods under test, if they, too, have if else branches, the method should be refactored.
4. Name of the method should be the kind of test. For instance, TestMakeReservation is different from TestMakeNoReservation().

Charlie Poole, author of NUnit, rewords one Assert per to test to one “Logical Assert” – saying “Sometimes, due to a lack of expressiveness in the testing api, you need to write multiple physical asserts to achieve the desired result. Much of the development in the NUnit framework api has been out of an attempt to get a single assert to do more work.”

Bryan Cook produces a considerable list of his own:

1. DO: Name Fixtures consistently
2. DO: Mimic namespaces of Target Code
3. DO: Name Setup/TearDown methods consistently
4. CONSIDER: Separating your Tests from your Production Code
5. DO: Name Tests after Functionality
6. CONSIDER: Use "Cannot" Prefix for Expected Exceptions

Bryan has over a dozen more suggestions.

Finally a couple of people suggested Gerard Meszaros’s book: “xUnit Test Patterns: Refactoring Test Code”

Previously on InfoQ: Recommended TDD Tutorials, Designing for Testability, Unit Testing Tips from Googleand Making TDD Stick: Problems and Solutions for Adopters

1. Back to top

   Re: Guidelines for Better Unit Tests

   Jul 24, 2009 7:39 AM by Christoph Kutzinski

   > CONSIDER: Separating your Tests from your Production Code
   
   
   
   No, don't consider it - do it!
   
   Don't let ANY test code slip into your production environment!

   Reply

2. Back to top

   Re: Guidelines for Better Unit Tests

   Jul 24, 2009 7:55 AM by Mark Levison

   Agreed - but I can't change other people's words. I think the key point is your tests are code think carefully about them and treat them nicely.

   Reply

3. Back to top

   Typo?

   Jul 24, 2009 8:31 AM by Kerry Buckley

   production code is the only place that you should do your refactoring.

   
   
   Surely "...is not the only place..."?

   Reply

4. Back to top

   Long Bean (Pojo) UnitTesting

   Jul 24, 2009 9:34 AM by Faisal Basra

   What if, I have a very long object, basically we have an enterprise application, We have a very big object named Proposal, that contains several nested child objects, then how I can test it integrated with all child populated. We have Spring with Hibernate configured.
   
   Looking expert advice.

   Reply

5. Back to top

   Re: Typo?

   Jul 24, 2009 12:16 PM by Mark Levison

   Thanks typo. Sorry for the mistake.

   Reply

6. Back to top

   Re: Long Bean (Pojo) UnitTesting

   Jul 26, 2009 3:30 AM by jean-simon Larochelle

   You should start by extracting the nested class to separate package visibility class. If the nested class are not static you will probably have to add a parameter to the constructor where you will use 'this' as a parameter. I find myself avoiding nested class more and more because in the end they make class bigger and more difficult to test. If you extract those you might even be able to use 'mocks' if you add interfaces to them.
   We use the DbUnit extension to test database stuffs. Search the Web for tips on testing Hibernate based code.

   Reply

7. Back to top

   I would add rule -1

   Jul 26, 2009 3:33 AM by jean-simon Larochelle

   Any tests is better than none.

   Reply

8. Back to top

   Re: Long Bean (Pojo) UnitTesting

   Jul 27, 2009 11:53 AM by James Richardson

   do you mean a RunnerBean?

   Reply

9. Back to top

   Another book (for dotnet shops..)

   Jul 28, 2009 2:04 PM by HJ Meulekamp

   I'm currently reading the art of unittesting
   
   www.artofunittesting.com/
   
   
   
   I think it is a great practical programmers book, reviewers on amazon seem to agree with me..

   Reply

10. Back to top

    Test code IS production code

    Aug 12, 2009 6:52 AM by Piers Thompson

    “Tests are code too, give them some love”
    
    
    
    I prefer "Test code IS production code".
    
    Good developers have a refined sense of what isn't appropriate in production code (long methods, meaningless identifiers, cut'n'paste, complex 'if' statements, code formatting etc etc etc) which doesn't always get applied to the test code - "it's only test code - bad practices don't really matter as long as it works".
    
    This is symptomatic of having working on projects without a large automated test suite that needs to be maintained along with the code. If you have such a suite then maintaining it is as significant a consumer of development effort as maintaining the non-test code. Therefore you must pay attention to the maintenance costs of your test code - and that means applying all the usual good practices to the test code as well as the non-test code.
    
    
    
    Remember - "Test code IS production code".
    
    
    
    
    P.

    Reply

11. Back to top

    Re: Another book (for dotnet shops..)

    Aug 14, 2009 2:53 PM by Mark Levison

    I've had a chance to read this book, but like you have heard good things about it.

    Reply

12. Back to top

    Re: Test code IS production code

    Aug 14, 2009 2:54 PM by Mark Levison

    "Test code IS production code" - I like it. An even better statement.

    Reply

13. Back to top

    Interesting video on unit testing

    Aug 18, 2009 6:36 PM by Franco Martinig

    Kevin Henney made an excellent presentation on this topic at Oredev 2008. You can watch the video on www.testingtv.com/2009/08/18/know-your-units/

    Reply

14. Back to top

    Re: Test code IS production code

    Oct 17, 2009 3:54 AM by Leonid Maslov

    I really like Your statement, I would like to think of it myself :))
    Trying to tell the same in my article. In my opinion tests are the most fragile part of application production code , the one you would like to be as much readable and clear it could be, the simplest it could be and s on... Actually all the qualities You would like to have to your business/mission critical code :)))

    Reply

• Older >