The theoretical mechanism and parametric testing of JUnit

JUnit began introducing theoretical mechanisms from version 4.4, it allows developers to design test cases from the beginning, you can use the parameter set (theoretically infinite parameters) of the object to the general description, by passing the constructed parameter set traversal into each case, to achieve the test object coverage. A simple example is as follows:

Import static org.junit.assert.*;
Import Org.junit.experimental.theories.DataPoint;
Import org.junit.experimental.theories.Theories;
Import org.junit.experimental.theories.Theory;
Import Org.junit.runner.RunWith;

@RunWith (theories.class) public
class Testboolean {

	@DataPoint public
	static Boolean Parama = true;
	@DataPoint public
	Static Boolean paramb = false;
	
	@Theory public
	void TestCase (Boolean param) {
		asserttrue (param);
	}

}

The two parameters declared in the code Parama, Paramb, are rotated into the use case as the data source, and the use case filters the data source through the parameters. If the int type data source is also declared, it is not passed into the testcase because it accepts only the Boolean type parameter. If testcase needs to use more than one data source, it can be extended in the parameter list, such as TestCase (Boolean Parama, Boolean paramb), Parama, Paramb traverse the incoming testcase, and there will be four combinations. Of course, you can also set different types of parameters.

The main points to use are as follows:

1, the designated Operation runner for Theories.class

2, parameter set with @datapoint annotation, and must be public static type

3, the concrete use case does not use @test annotation, but @theory annotation

Unfortunately, Eclipse's support for the junit theory mechanism is not good, as the above testcase,case will certainly fail when it runs to the second time, but Eclipse is not prompted to fail, but rather throws an exception directly, and when you click through the JUnit window to enter the code, The warning window will pop up:

Another drawback of the junit theory mechanism is that the data sources are hard-coded and cannot be configured dynamically through configuration files.

In view of the above deficiencies in the theoretical mechanism, it is recommended that junit parameterization tests be used directly for requirements with different data sources, similar examples are as follows:

Import static org.junit.assert.*;
Import Java.util.Arrays;
Import java.util.Collection;
Import Org.junit.Test;
Import Org.junit.runner.RunWith;
Import org.junit.runners.Parameterized;
Import org.junit.runners.Parameterized.Parameters;

@RunWith (parameterized.class) public
class Testboolean {

	private boolean param;

	@SuppressWarnings ("Rawtypes")
	@Parameters public
	static Collection data () {return
		arrays.aslist (new Object[][] {{true},
				{false}});

	Public Testboolean (Boolean param) {
		this.param = param;
	}
	
	@Test public
	void TestCase () {
		asserttrue (param);
	}

}

Similar to the theoretical mechanism, parametric testing puts the data source into a static container with several sets of parameters, and the use cases run several times, and each time it executes with different parameters. When a use case fails, detailed failure information is also given, which can be directly positioned in the JUnit window:

The main points to use are as follows:

1, the designated Operation runner for Parameterized.class

2. The parameter set is used in a container with a return type collection, annotated with @parameters, and must be a public static type

3, need to declare the corresponding type of variable, in the construction method to retrieve the specified parameters

4. Use the @test annotation for the concrete use case, and do not need to pass in the formal parameter

5, the parameter set is a two-dimensional array, the first dimension specifies a total of several sets of parameters (that is, how many times the case to run), the second dimension specifies the number of each set of parameters (this article only uses a Boolean parameter, some cases may require multiple parameters)

In addition to being intuitive to run, parameter sets can be dynamically configured with a configuration file to construct code that contains only one parameter (assuming that the configuration file is a string with commas separated between the data):

@Parameters public
	static Collection data () {
		String strtemp = Property.getvalue ("params");
		string[] arraytemp = Strtemp.split ("\,");
		if (Arraytemp.length > 0) {
			List arrayList = arrays.aslist (arraytemp);

			object[][] tt = new object[arraylist.size ()][1];
			for (int i = 0; i < arraylist.size (); i++) {
				tt[i][0] = Arraylist.get (i);
			}

			Return Arrays.aslist (TT);
		} else {
			fail ("Params in Configure file is null!");
			return null;
		}
	}