> If the > latter works speedily enough against the real store, more > power to you, but in systems without that, well, it's just > scary.
Speed can indeed be an issue but deciding that speed is the only factor to decide what a unit test is is, in my opinion, short-sighted.
Sometimes, unit tests go fast, sometimes they go slow. Sometimes, functional tests go fast and sometimes they go slow. There is no mutual exclusion between the concept of speed and that of unit tests.
Once I had accepted this idea, it was clear to me that the right way to tackle this problem in TestNG was to let users specify exactly what they wanted to run and give them a chance to "tag" tests appropriately.
Using groups in TestNG, you can therefore tag your test methods as "database" or "front-end" but you can also make them belong to the group "long" or "short". This effectively blurs the vague notion of "unit tests" and lets the users decide what they want to do pragmatically.
Want a quick sanity check before committing code? Run all the "short" tests, regardless of whether they exercise the database or the network.
Want a full functional coverage to make sure absolutely nothing is broken in your product? Run the "long" tests (or the "integration" ones).
You modified a schema and want to make sure you didn't break anything? Just run the "database" tests.
Groups are a very powerful and addictive feature once you start using them...
Previous Topic
