I don't mean to imply that unit tests should be independent to the point that don't really test anything.  Assume you have a test class called CustomerDaoTests which include the following methods:  CanInsertNewCustomer, CanGetCustomerById, CanGetCustomerByExample, CanDeleteExistingCustomer.  Each test should be able to run and pass, independent of having to run any of the other unit tests.  So if you run CanInsertNewCustomer by itself, it'll successfully run.  Likewise, if you run CanDeleteExistingCustomer by itself, it'll also successfully run by itself.

Any of these tests, even run independently of each other, may rely on a plethora of infrastructure such as DAOs, app.config files, HBMs, NHibernate, etc.  But the point is that they can run independently of running other unit tests.

Going back to the example, CanInsertNewCustomer should get rid of the customer after it's been inserted to return the DB to its original state.  Likewise, the customer needs to exist before the test CanDeleteExistingCustomer can be run.  NDbUnit can be used to clean the database after CanInsertNewCustomer and populate the database before CanDeleteExistingCustomer.  This allows you to test each bit of functionality without creating interdependencies among the unit tests.

Another approach, instead of creating separate insert, get, delete unit tests, and without having to use a tool such as NDbUnit is to create a single unit test called CanPerformCustomerLifeCycle, or somethin like that.  This test would insert the customer, get the customer just inserted and then delete the customer.  The key is that this happens in a single unit test which can run independently of other unit tests being run before it or after it.  The drawback to this "full object life-cycle in one unit test" is that the unit test is essentially violating the single responsibility principle.  It might sound a bit esoteric at first, but sticking to a single responsibility in each unit test keeps the unit tests atomic and will serve to alert you to the exact problem that's occurring if and when a bug is introduced.

Mark,

The NUnit SetupFixture and Setup methods may be run alongside a unit test and still be able to consider that unit test as being independent of other unit tests.  This is very much what NDbUnit does:  performs the DB setup, allows you to run your test, and then performs any necessary rollback.

The major problem I encountered in the code I was detangling was that four unit tests needed to be run in the correct sequential order in order for each subsequent unit test to pass.  So if you didn't run all of the first three, in the correct order, then the fourth unit test would fail.  I should be able to run the fourth unit test without having to worry about running any other unit tests in any special order.

That's an interesting addition to an xUnit tester.   With the added ability to define unit test dependencies explicitly rather than implicitly, via top-to-bottom test ordering, then it certainly becomes less of a concern to maintain independence.  On the other hand, it also seems to turn the idea of a unit tester (emphasis on "unit") into a user-story tester.  Although I can see some value for it for short "do/undo" scenarios (e.g. specifically with the insert/delete example) I would lean towards Fit and/or StoryTeller to manage tests involving test dependencies.  I'm thinking of Fit's ActionFixture, specifically.

If used with tight discipline, I think TestNG could be used as both a unit tester and a user-story tester.  But I'd be worried about developers making it nearly impossible to test a single piece of functionality due to the unit test depending on a chain of four others.  To interpret the results of the fifth, you'd have needed to review, in detail, the execution and results of the previous four.  To mitigate, the developer could simply make a new unit test to isolate the testing of specific code; but then testing overlap has been introduced to the unit tests.  I understand that some overlap is inevitable, but the less, the better for minimizing unit test maintenance.

I've observed that unit tests which are hard to understand, complicated to follow, or hard to run in isolation, tend to stop being run altogether.  Then again, that's why we (should) have continuous integration environments. ;)

I would agree that there are definitely exceptions to the rule of keeping tests completely independent, but, IMO, it should be an exception rather than a norm.  Unit tests that are dependent on an order and, therefore, on each other usually end up being fragile tests.

AndyB,

There are certainly times when testing multiple facets of logic concurrently is warranted and desirable.  Fit (http://fit.c2.com/) is a great tool for testing these types of integrated tests.  A simple add/delete wouldn't necessarily warrant the introduction of such a framework, but it begins to become useful quite quickly when you want to look at the results of multiple actions sequentially.