CODEWITHSUNDEEP
javaunit-testingjunit
MePsyDuck
MePsyDuck

Reputation: 374

Maintaining order of execution of tests in Junit

Currently, I'm working on testing a Class (let's say Message for example) that has CRUD operations. Following the methodology used behind, I want to test all the operations in exact Create, Read, Update and Delete order.

Since the order of execution of test cases in JUnit is dependent on JVM, I need some proper way to ensure that the unit test cases are executed in the given order.

So far, I've come up with following strategies:

  1. Using @FixMethodOrder(MethodSorters.NAME_ASCENDING) in JUnit 4 to execute methods in ascending order of their names. However, this requires renaming test cases and didn't seem the best way to me as if in future more test case need to be added existing test cases may need to be refactored.

  2. Using different Message object for each test case. However, I will need to create/initialize it before and delete it after each test case. This for me seems to go against the notion of unit-testing, as to test update I'll have to call create and delete, which no longer makes this a unit test case. If create fails, this would result in read, update and delete tests in failing as well, even when there's nothing wrong with them.

  3. Using a single test to call other test methods. This to me seems the more appropriate solution than other two. If create fails, it should stop other three tests from running and such.

So is there any better way to achieve this or any alternative way to test such a model?

Currently using JUnit4 and thinking of moving to JUnit5 if no solution satisfies my case.

Upvotes: 0

Views: 964

Answers (2)

Dirk Herrmann
Dirk Herrmann

Reputation: 5949

Your option 2 is the most appropriate one, even if this surprises you: You should try to make your tests independent of each other such that execution order is not an issue.

And, it is a normal situation that, for the testing of some method a, you need to call other methods b, c, ... during test setup, validation or teardown. Your are right, if these other methods fail then tests for method a will probably fail as well - or succeed where they should fail.

This, however, is not a problem if you also have tests for those other methods b, c, ... in place. If there is a bug in, say, b, then some test for b would fail and some other tests for a. From the pattern of failing and succeeding tests you would then have to deduce where to search for the root cause of the failing tests.

Upvotes: 1

Januson
Januson

Reputation: 4861

What you are describing are not Unit Tests.

A Unit Test should never:

  • Touch a database
  • Touch a filesystem
  • Touch a network
  • Depend on another test

What you should do instead is to mock access to such external resources so that your tests are isolated and independent.

Upvotes: 3

Related Questions