

Key qualities of a good unit test - Kennethtruyers
http://www.kenneth-truyers.net/2012/12/15/key-qualities-of-a-good-unit-test/

======
mscarborough
I agree with this article, except increasingly I have been writing tests that
do not completely avoid the full database connection. Wherever possible, it is
avoided by writing smaller methods that take parameters and can be tested
independently of where the data does or doesn't live...but this won't
completely work. I know it's not the purest way, but running against a test
copy of the schema provides a couple benefits:

The actual behavior of the app is tested. For example, some web frameworks
will have different behavior when you compare the behavior of their Model
validation classes with and without foreign key constraints at the schema
level. Not running this level of integration means that you're not really
understanding how the app behaves, and mis-documenting its behavior with your
tests.

Another issue I have encountered is ensuring the proper load order of fixture
data. In CakePHP for example, I haven't been able to manage this adequately.
Cake uses a test database for unit tests, and for a lot of inter-related
tables with foreign keys, you can trigger DB errors before your tests even run
if the constraints fail.

Finally, running this type of test suite on dev/stage/prod can be a quick way
to verify that the full stack is behaving as expected. You can read any
configs specified in the codebase and rely solely on committed, versioned
code.

Perhaps this is just a result of using the wrong tools, and other
languages/frameworks seem to have this down a bit better. Rails and rspec have
worked a bit better for me.

In any case, each project I work on has a front-end test suite that logs in,
scrapes all known pages, and tests those results. These are using the DB also
and from the app's point of view, the incoming requests mimic that of a real
user.

