Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to introduce what is unit testing, and how to write good unit test to a friend. I think it's better if I give him some principles for a good unit test, and suddenly I remember about "ACID" properties of transaction:

A - atomic: a unit test should test only one thing

C - consistent: a unit test, if passed, should pass thousand times, whenever you run it, so it should not depend on external things, such as network, database...

I - independent: a unit test, should be independent from others, therefore, you can run unit tests in every order, without changing the result.

But i get a bit stuck with "D" - durable. Durable unit test? It makes no sense. Any suggestion about this D?

Thank you.

share|improve this question
Do not force it if it ain't coming. Tests are not databases. I am not sure about C. It is OK for tests to depend on network, on database, but those tests are not to be called 'unit' tests. –  Job May 19 '11 at 2:53
@Job The question specifically talks about unit tests, so I think 'C' is fine. –  Anna Lear May 19 '11 at 3:01
@Job: why do I have to talk about other things, when I only want to talk about unit testing??? –  Vimvq1987 May 19 '11 at 3:16
@Job Fair points, but there's a bit of a jump from a question about unit testing to assuming that the OP doesn't use any other types of tests. –  Anna Lear May 19 '11 at 3:35
IMHO forcing an acronym from a very different area of expertise upon unit tests at best won't help your friend understand unit testing better - or at worst it may just confuse him even more. –  Péter Török May 19 '11 at 8:49

4 Answers 4

How about this:

Change C to comprehensive: A comprehensive test should test all aspects of a function (e.g. test many different possible inputs and verify every possible output).

And then set D to deterministic: (taken from C - consistent): a unit test, if passed, should pass thousand times, whenever you run it, so it should not depend on external things, such as network, database...

share|improve this answer
Add F = Fast/Functional, and L = Laconic, and you get FLACID! By the way, Comprehensive is a property of a test suite, not a test itself. –  Job May 19 '11 at 3:10
unit tests should not be comprehensive, but they should be determinisitic –  Steven A. Lowe May 19 '11 at 3:56
@Steven - a devils advocate thing - how about extra random tests (since the determistic tests aren't comprehensive) which log the random choices if/when they fail? Could be a way to catch a few extra bugs over time. –  Steve314 May 19 '11 at 4:21

Translating "atomic" as testing only one thing is a pretty serious stretch. Atomic really means that an external view, the transaction either completely succeeds, or else completely fails and there's no evidence left (except maybe in some log files or such) that it ever happened at all.

As such, you generally do not want unit tests to be atomic. Quite the contrary, if some tests succeed and others fail, you want to know exactly which ones succeeded and which failed. You want results to have the granularity to let you know exactly what failed and (if possible) as exactly as possible why it failed. Yes, in some cases (especially early stages of development) you expect a unit to fail tests -- but you still want to know that it's failing the tests you expect to fail, and preferably that it's failing for exactly the expected reasons.

share|improve this answer

There is already an acrynome for Unit Testing principles available, close to what you outlined.



The faster your tests run, the more often you’ll run them.


Each unit test should have a single reason to fail.


You should obtain the same results every time you run a test.

Self verifying

A good unit test fails or passes unambiguously. When all tests run green, you have high confidence that you can ship the code to the next level (likely the acceptance test automated suite).


Tests written first specify the behavior that you’re about to build into the code.

Source: http://pragprog.com/magazines/2012-01/unit-tests-are-first

Also at page 132 of Clean Code

share|improve this answer

One idea is that "Durable" might imply that a test shouldn't depend on the behaviour of things that aren't stable, other than the particular features being tested.

Reasonably predictable changes elsewhere in the code shouldn't result in large numbers of unit tests needing updates. If this happens too much, the costs of unit testing increase relative to the benefits. Hypothetically this could make unit testing non-viable.

A bit obvious, a bit hardly-worth-saying-out-loud, but then again...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.