Yesod Web Framework
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Guidelines for Better Unit Tests
Posted by Mark Levison on Jul 24, 2009
Jimmy Bogard, wrote an article: “Getting value out of your unit tests”, where he gives three rules:
- “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.
- “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?”
- “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:
- One Assert per test (where possible).
- If there are any "if else" inside a test, move the branches to individual test methods.
- Methods under test, if they, too, have if else branches, the method should be refactored.
- 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:
- DO: Name Fixtures consistently
- DO: Mimic namespaces of Target Code
- DO: Name Setup/TearDown methods consistently
- CONSIDER: Separating your Tests from your Production Code
- DO: Name Tests after Functionality
- 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
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Transforming Software Delivery: An IBM Rational Case Study
Five Key Practices to Agile ALM
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Re: Guidelines for Better Unit Tests
by
Christoph Kutzinski
Posted
Re: Guidelines for Better Unit Tests
by
Mark Levison
Posted
Typo?
by
Kerry Buckley
Posted
Re: Typo?
by
Mark Levison
Posted
Long Bean (Pojo) UnitTesting
by
Faisal Basra
Posted
Re: Long Bean (Pojo) UnitTesting
by
jean-simon Larochelle
Posted
Re: Long Bean (Pojo) UnitTesting
by
James Richardson
Posted
I would add rule -1
by
jean-simon Larochelle
Posted
Another book (for dotnet shops..)
by
HJ Meulekamp
Posted
Re: Another book (for dotnet shops..)
by
Mark Levison
Posted
Test code IS production code
by
Piers Thompson
Posted
Re: Test code IS production code
by
Mark Levison
Posted
Re: Test code IS production code
by
Leonid Maslov
Posted
Interesting video on unit testing
by
Franco Martinig
Posted
-
> 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! -
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.
-
production code is the only place that you should do your refactoring.
Surely "...is not the only place..."? -
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. -
Thanks typo. Sorry for the mistake.
-
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. -
Any tests is better than none.
-
do you mean a RunnerBean?
-
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.. -
“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. -
I've had a chance to read this book, but like you have heard good things about it.
-
"Test code IS production code" - I like it. An even better statement.
-
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/
-
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 :)))
14 comments
Watch Thread Reply