Quick Guide: Test execution sequence of JUnit method android

JUnit in version 4.x is a test framework which uses annotations to identify methods that specify a test. The main websites for JUnit are the JUnit homepage (http://junit.org/) and the Github project page (https://github.com/junit-team/junit). Here we will discuss the execution sequence of JUnit method android.

 A JUnit test is a method contained in a class which is only used for testing. This is called a Test class. To write a JUnit 4 test you annotate a method with the @org.junit.Test annotation.

This method executes the code under test. You use an assert method, provided by JUnit or another assert framework, to check an expected result versus the actual result. These method calls are typically called asserts or assert statements.

You should provide meaningful messages in assert statements. That makes it easier for the user to identify and fix the problem. This is especially true if someone looks at the problem, who did not write the code under test or the test code.

JUnit method android

JUnit 4.x uses annotations to mark methods as test methods and to configure them. Below gives an overview of the most important annotations and methods in JUnit.

1. Ordering test methods

The simplest test case you can write in JUnit is to annotate methods with @Test:
package test;

import org.junit.Test;
public class OrderTest1 {
    public void test1() {
        println("@Test test1()");
    public void test2() {
        println("@Test test2()");
    private void println(String string) {
        OrderTestUtils.println(OrderTest1.class, string);

In OrderTest1, the execution sequence of JUnit order is:
OrderTest1 @Test test1()
OrderTest1 @Test test2()

2. Managing test fixtures

If you need to initialize the same data for each test, you put that data in instance variables and initialize them in a @Before setUp method. The setUp method is called before each @Testmethod.

One test invocation becomes the following call sequence:

  • Call @Before setUp
  • Call one @Test method

If that data needs to be cleaned up, implement a @After tearDown method. The tearDown method is called after each @Test method.

One test invocation becomes the following call sequence:

  • Call @Before setUp
  • Call one @Test method
  • Call @After tearDown

The call sequence for a class with two test methods is:

  • Call @Before setUp
  • Call @Test method test1
  • Call @After tearDown
  • Call @Before setUp
  • Call @Test method test2
  • Call @After tearDown

3. Managing expensive test fixtures

When a resource is expensive to manage like a connection to a server, a database, or even managing an embedded server, it’s best to only initialize that resource once for the whole test case. You want to avoid starting and stopping a server for each @Test method. Instead, initialize the server once for all the tests in the class.

To do so, we use @BeforeClass and @AfterClass methods, instead of @Before and @After to get the following call sequence:

  • Call @BeforeClass setUpClass
  • Call @Test method test1
  • Call @Test method test2
  • Call @AfterClass tearDownClass

4. Subclassing test cases with managed resources

Here, things get trickier.

The order of @Before methods goes from the top to the bottom of the hierarchy: parent, child, child of a child.

The order of @After methods goes from the bottom to the top of the hierarchy: child of child, child, parent.

5. Manage Test order

Let’s start with a rule: You should not create test methods that depend on the order in which they are executed.

If you do have such tests and they are failing randomly or rarely, this is why: JUnit relies on Java’s reflection API to get which test methods to execute. The problem is that the API does not define the order of the methods it returns. Your tests may work for a long time and then fail, apparently randomly. The things are, you’ve just been lucky all along and relying on the Java run-time giving you a consistent answer when it makes no such guarantee.

You may even see some very confusing behavior like a superclass’ test methods being mixed in with its subclass. I’ve seen this in Eclipse and Ant for example.

JUnit 4.11 provides a workaround for this behavior with a new class-level annotation:  FixMethodOrder(MethodSorters.NAME_ASCENDING).

The annotation FixMethodOrder sorts the test methods in lexicographic method name order and uses Method#toString() to break ties.


You should focus your Android tests on testing the business logic of your application. Here we get the execution sequence of JUnit method android. A good rule of thumb is to have the following distribution of tests:

  • 70-80 % unit tests to ensure stability of your code basis
  • 20-30 % functional tests to ensure that the application really works
  • some cross-functional tests if your application integrates intensively with other Application components


For further reading:

Leave a Comment

Scroll to Top