I had a conversation with my friend as follows:

- How can I run my unit tests in some specific order Çetin? I need to execute them in order, otherwise some of my tests fail.
- Unit tests must be “independent”. So, you don’t need any order in fact and you can’t guarantee it also.

I tried to explain him why they must be independent shortly. After this conversation, I opened my unit test reference book (Pragmatic Unit Testing in Java with JUnit) and looked again the properties of good unit tests to refresh my memory. Let’s remember them together briefly:

• Automatic
  Unit tests need to be run automatically. Invoking one more unit tests can’t be any more complicated than pressing one button in the IDE or typing in one command at the prompt.

  Don’t introduce a test that breaks the automatic model by requiring manual steps. Think about a man sitting in front of the machine waiting for popups to confirm. It is not we want. Whatever test requires (database, network connection etc.) make these an automatic part of the test.

  A machine should be running all of the unit tests for all checked-in code continuously. This automatic check ensures that whatever is checked-in hasn’t broken any test, anywhere. Investigate systems such as Cruise Control, Hudson, Teamcity, Anthillpro, Apache Continuum etc.

  Test must determine for itself whether it passed or failed. It means you don’t have to think about it. No one needs to read the test results to check whether the code is working or not.

• Thorough
  Good unit tests are thorough; they test everything that’s likely to break. But just how thorough? Every line of code, branch, exception or most likely candidates for error like boundary conditions, missing and malformed data, and so on. It’s a question of judgment, based on the needs of your project (time, effort, budget). If you want to aim for more complete coverage, then you may want to invest in code coverage tools (EMMA, Cobertura, Clover etc.) to help.

• Repetable
  The goal is that every test should be able to run over and over again, in any order, and produce the same results every time. This means that tests cannot rely on anything in the external environment that isn’t under your direct control.Use mock objects (JMock, EasyMock, JMockit, and so on) as necessary to isolate the item under test and keep it independent from the environment.

  Each test should produce the same results every time. If it doesn’t, then that should tell you that there’s a real bug in the code.

• Independent
  Tests need to be kept independent from the environment and each other. Make sure you’re only testing one thing at a time. It doesn’t mean that you use only one assert in a test, but that one test method should focus on a method, or a small set of production methods that, together, provide some feature.

  Independent also means that no test relies on any other test; you should be able to run any individual test at any time, and in any order. You don’t want to have to rely on any other test having run first. Use per-test and per-class setup/teardown methods to get a fresh start.

• Professional
  The code you write for a unit test is real. This means that it must be written and maintained to the same professional standards as your production code. You write lots of test code (as much as real code) therefore, test code needs to be kept neat and tidy, well designed and well-factored, just as professional as the production code.

So, a-trip always makes you feel good.
Happy testing.

Source: Pragmatic Unit Testing in Java with JUnit