Art Of Unit Testing - Book Wiki > Chapters > 7. The pillars of good unit tests

7. The pillars of good unit tests

 Starting Paragraph

No matter how you organize your tests, or how many you have. It you can’t trust them enough they aren’t worth squat. In fact, the tests that you write should have three properties that together make them “good” in my eyes. They are:  

§Trustworthy  

§Maintainable  

§Readable  

This chapter deals with these three pillars of “Good” tests with a series of practices you can use as a checklist when doing test reviews in your team. Being able to trust a test will make sure your developers will actually want to run the tests they write, and will listen to the test results with confidence. It also means making sure the tests themselves don’t have bugs and that they are testing the right thing.A non-maintainable test is the worst nightmare for projects that have them, since they pose a schedule risk, or the risk of losing the tests the minute the project goes into a more aggressive schedule. People will simply stop maintaining and writing tests that take to long to change. Readability is not only about being able to read a test but also about being able to figure out where the bugs are and are not. Without readability the other two pillars fall apart pretty quick – maintaining the tests becomes harder, and thus you can’t trust them anymore.  

Together, the three pillars make a sound investment of your time. Drop just one of them and you run the risk of wasting everyone’s time.  

   

Comments? Errata?

   

Tag page
Viewing 4 of 4 comments: view all
page 125, listing 7.12, Assert.That(valid, Is.False) fix the assert line
Posted 10:58, 15 Oct 2008
page 121, first paragraph after listing 7.6 paragraph references listing 8.2. The correct is to reference listings 7.5 and 7.6
Posted 11:14, 15 Oct 2008
page 120, first paragraph paragraph references book (Feathers n.d.). There is not clarification of name of book or other details about it
Posted 11:16, 15 Oct 2008
page 117, paragraph starting with "Making test methods be monster tests..." you say that "test monsters should be added and not replaced" but before that you discourage using monster tests!!
Posted 11:18, 15 Oct 2008
Viewing 4 of 4 comments: view all
You must login to post a comment.