When is a Test not a Unit-test?

Question

I am looking for rules like:

A test is not a unit-test if:

• it communicates with a database
• it cannot run in parallel with other tests

Answer 1

Intricate question.

Say I am to program some business logic and all business logic needs to get to the data via some form of DAL.

Say that for the purposes of testing, I mock the DAL units (by creating "mockingbirds").

But those mockingbirds are of course, additional units in their own right. So even when using mocks, it might seem like I'm still bound to violate the idea of "no other units involved" when I want to unit-test my business logic module.

Of course, it is generally known that "creating mockingbirds for the DAL" can invalidate your very test itself on the count that your mockingbird deviates in some particular aspect from the DAL.

Conclusion : it is outright impossible to do "genuine unit-tests" on business modules that depend in any way on any kind of DAL, question mark ?

Corrolary : the only thing that can possible be ("genuinely" !) unit-tested is the DAL itself, question mark ?

Corrolary of the corrolary : given that the "DAL" is usually either an ORM or the very DML of some DBMS, and given that those products are usually bought as being "proven technology", what is the added value of doing any unit tests what so ever, question mark ?

Answer 2

A test is not an Unit Test when:

• it tests more than one thing at once (i.e. it tests how two things work together) - then it is an integration test

Checklist for good unit tests:

• they are automated
• they are repeatable
• they are easy to implement
• they remain for future use, once written
• they can be run by anyone
• they can be run by the push of a button
• they run quickly

Some more best practices (in no particular order of importance):

• tests should be separated from integration tests (which are slower), so that they can be run fast as frequently as possible
• they should not comprise too much logic (preferably, no control structures)
• every test should test only one thing (thus, they should contain only one assert)
• the expected values used in assertions should be hard-coded and not computed at test run-time
• external dependencies (filesystem, time, memory etc.) should be replaced by stubs
• test should recreate the initial state at test shutdown
• in assertions, it is better to use a "contains..." policy, rather than "is strictly equal..." policy (i.e. we expect certain values in a collection, certain characters in a string etc.)

This is part of the knowledge I have extracted from Roy Osherove's book - The Art of Unit Testing