Skip to content


Properties of Good Tests: A-TRIP

I had a conversation with my friend as follows:

- How can I run my unit tests in some specific order Çetin? I need to execute them in order, otherwise some of my tests fail.
- Unit tests must be “independent”. So, you don’t need any order in fact and you can’t guarantee it also.

I tried to explain him why they must be independent shortly. After this conversation, I opened my unit test reference book (Pragmatic Unit Testing in Java with JUnit) and looked again the properties of good unit tests to refresh my memory. Let’s remember them together briefly:

  • Automatic
    Unit tests need to be run automatically. Invoking one more unit tests can’t be any more complicated than pressing one button in the IDE or typing in one command at the prompt.

    Don’t introduce a test that breaks the automatic model by requiring manual steps. Think about a man sitting in front of the machine waiting for popups to confirm. It is not we want. Whatever test requires (database, network connection etc.) make these an automatic part of the test.

    A machine should be running all of the unit tests for all checked-in code continuously. This automatic check ensures that whatever is checked-in hasn’t broken any test, anywhere. Investigate systems such as Cruise Control, Hudson, Teamcity, Anthillpro, Apache Continuum etc.

    Test must determine for itself whether it passed or failed. It means you don’t have to think about it. No one needs to read the test results to check whether the code is working or not.

  • Thorough
    Good unit tests are thorough; they test everything that’s likely to break. But just how thorough? Every line of code, branch, exception or most likely candidates for error like boundary conditions, missing and malformed data, and so on. It’s a question of judgment, based on the needs of your project (time, effort, budget). If you want to aim for more complete coverage, then you may want to invest in code coverage tools (EMMA, Cobertura, Clover etc.) to help.
  • Repetable
    The goal is that every test should be able to run over and over again, in any order, and produce the same results every time. This means that tests cannot rely on anything in the external environment that isn’t under your direct control.Use mock objects (JMock, EasyMock, JMockit, and so on) as necessary to isolate the item under test and keep it independent from the environment.

    Each test should produce the same results every time. If it doesn’t, then that should tell you that there’s a real bug in the code.

  • Independent
    Tests need to be kept independent from the environment and each other. Make sure you’re only testing one thing at a time. It doesn’t mean that you use only one assert in a test, but that one test method should focus on a method, or a small set of production methods that, together, provide some feature.

    Independent also means that no test relies on any other test; you should be able to run any individual test at any time, and in any order. You don’t want to have to rely on any other test having run first. Use per-test and per-class setup/teardown methods to get a fresh start.

  • Professional
    The code you write for a unit test is real. This means that it must be written and maintained to the same professional standards as your production code. You write lots of test code (as much as real code) therefore, test code needs to be kept neat and tidy, well designed and well-factored, just as professional as the production code.

So, a-trip always makes you feel good.
Happy testing. :D

Source: Pragmatic Unit Testing in Java with JUnit

Posted in TDD.

Tagged with , , , .


3 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. mstf says

    nice,thanks.
    from my experiences,i also have some practical advise addition to cetin(especially for C programmers)

    **unit tests should be written just for public methods, if you need to write test for a private method,check your classes again.

    **do not forget to test copy constructors

    TestC1_Method
    {
    C1* pInst_c1 = new C1(); //C1 is a class
    C1* pInst_c2 = new C1();

    pInst_c1->DoSomeStateChange;

    pInst_c2 = pInst_c1; –>everything is fine?

    delete pInst_c1;

    pInst_c2->RunYourMethods –>is it ok?
    }

    But these are for the cases you have time,if you don’t have and your supervisor waits for release,fuck it.just write your code :) cause money is important :)

  2. Azauskas says

    Thank you..Viva TDD :)

Continuing the Discussion

  1. A blind spot of Continuous Integration « Schneide Blog linked to this post on December 29, 2009

    [...] are rules for good unit tests. A basic set are the A-TRIP rules formulated in the excellent beginner’s book “Pragmatic Unit Testing” by Andy Hunt [...]



Some HTML is OK

or, reply to this post via trackback.