Plug-in testing with MAVEN

Maven itself is not a unit testing framework, and the mainstream unit testing framework in Java is JUnit and testng. What Maven does is to execute JUnit or testng test cases through plug-ins when the build executes to a specific life cycle stage. This plug-in is Maven-surefire-plugin, as test run-time testing Runner, it can be compatible with JUNIT3, JUNIT4, TestNG.

The default life cycle in Maven, where the test phase is defined as "Run tests using the Unit test framework." The lifecycle phase needs to be bound to the target of a plug-in to do the real work, and the test phase is tied to the Maven-surefire-plugin's test target, which is a built-in binding.

By default, the Maven-surefire-plugin test target automatically executes all test classes that conform to a set of naming patterns under the testing source path (default is src/test/java/). Modes are:

1. **/test*.java: All Java classes named with Test start in any subdirectory
2. **/*test.java: All Java classes named end of Test in any subdirectory
3. **/*testcase.java: All Java classes named TestCase end in any subdirectory

As long as the test classes are named in the above pattern, MAVEN can run them automatically, and the user does not need to define test set Testsuite to aggregate test case testcase. It is important to note that test classes ending in tests are not automatically executed.

If necessary, you can also define the mode of running the test class yourself, and Maven-surefire-plugin also supports a more advanced TESTNG test collection XML file. In addition, to be able to run tests, MAVEN needs to introduce the dependencies of the test framework into the project, such as adding junit test scope dependencies.

• Skip Test

When you need maven to skip the test, add the parameter skiptests at the command line

$ MVN package-dskiptests

You can also configure the Maven-surfire-plugin plug-in to provide this property in the Pom. However, it is not recommended that you do not need to test the code if you need to skip the test for a long time.

Sometimes with the user not only want to skip the test run, but also want to temporarily skip the compilation of test code, you can use the following command (although not recommended):

$ MVN Package-dmaven.test.skip=true

The parameter Maven.test.skip simultaneously controls the behavior of both the Maven-compile-plugin and Maven-surefire-plugin plugins. So if the POM configuration is to be implemented, the POM configuration is as follows:

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-compiler-plugin </artifactid><version>2.3.2</version><configuration><skip>true</skip></ configuration></plugin><plugin><groupid>org.apache.maven.plugins</groupid>< Artifactid>maven-surefire-plugin</artifactid><version>2.10</version><configuration> <skip>true</skip></configuration></plugin>

• Dynamically specify the test cases to run

Running a single test case repeatedly is a common behavior in everyday development. For example, there is a failed test case in the project code, and the developer runs the test again to get a detailed error report. During the process of repairing the test, the developer will also run it repeatedly to confirm the correctness of the repair code. Running all tests over and over for just one failed test case can create unnecessary expenses, especially if you have more tests in your project.

Maven-surefire-plugin provides a test parameter that enables MAVEN users to specify the testing case to run at the command line. For example, if you only want to run Randomgeneratortest in Account-captcha, execute the following command:

$ MVN Test-dtest=randomgeneratortest

The parameter value here is the class name of the test case, which is the result of running only the Randomgeneratortest test class.

In addition, the parameter of this test also supports other assignment methods, such as:

$ mvn test-dtest=random*test match multiple characters with asterisks

$ MVN TEST-DTEST=RANDOMGENERATORTEST,ACCOUNTCAPTCHASERVICETETST specifying multiple test cases with commas

You can also mix asterisks and commas for use.

If no test class is matched, an error is reached and the build fails. According to the error prompts can add-dfailifnotests=false, tell Maven-surefire-plugin even if there is no test and do not error

• Include and exclude test cases

MAVEN advocates conventions over configuration, so users should try to follow the naming pattern naming of the test class. Even so, Maven-surefire-plugin allows users to customize other test classes, or to exclude some test classes that conform to the default naming method.

For example, some projects have test classes that end with tests, which do not conform to 3 modes. However, the following configuration allows Maven to run this type of test automatically:

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-surefire-plugin </artifactid><version>2.10</version><configuration><includes>**/*tests.java</ Includes></configuration></plugin>

As above, two asterisks * * are used to match any path, and an asterisk * matches 0 or more characters except the path delimiter.
Similarly, you can use the excludes element to exclude some test classes that conform to the default naming pattern, as follows:

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-surefire-plugin </artifactid><version>2.10</version><configuration><excludes><exclude>**/* Skiptest</exclude></excludes></configuration></plugin>

• Test report

In addition to the command-line approach, MAVEN can also use plug-ins to generate test reports in the form of files

1. Basic Test Report

   By default, Maven-surfire-plugin generates test reports in two formats in the project's Target/surefire-reports directory: Simple text Format and JUnit-compatible XML format

   For example, the TXT file in the target directory of Account-captcha is:

   -------------------------------------------------------------------------------
   Test Set:com.juvenxu.mvnbook.account.email.AccountEmailServiceTest
   -------------------------------------------------------------------------------
   Tests Run:1, failures:0, errors:0, skipped:0, Time elapsed:0.834 sec

   XML contains much more information, which can be found in JUnit's standard

2. Test Coverage Report

   Test coverage is an important metric for measuring code quality. Cobertura is an excellent open source test coverage statistics tool that Maven integrates with Cobertura-maven-plugin to generate reports using simple commands. The command is as follows:

   $ MVN Cobertura:cobertura

• Reusing test code

When you run the MVN package at the command line, MAVEN packages the project's main code and resource files, installs them, or deploys them to the warehouse, which can be used by others to achieve MAVEN project-level reuse. The default packaging method does not include the test code, so when using external dependencies, its artifacts generally do not contain the test code.

Then, reusing the test code of a module within a project is a common requirement. Perhaps the test code for one of the underlying modules contains some commonly used test tool classes, or some high-quality test base classes for inheritance. You will need to package the test class through Maven-jar-plugin, as follows:

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-jar-plugin</ Artifactid><version>2.3.2</version><executions><execution><goals><goal> Test-jar</goal></goals></execution></executions></plugin>

In the above configuration, Maven-jar-plugin has two targets, namely Jar and Test-jar, which run through MAVEN's built-in bindings in the package phase of the default life cycle, with the behavior of packaging the project master code. The latter does not have a built-in binding, so the plug-in configuration above shows that the target is declared to package the test code. By querying the plug-in's specific information, you can see that the default binding declaration period for Test-jar is the package, so when you run MVN clean, you can expect two targets to be executed, with the project master code and the test code packaged separately.

Now, you can use the test package widget with a dependency declaration, notice that the type element is declared as Test-jar in the dependency, and all test package artifacts use a special Test-jar packaging type. Note that you also use test-dependent scopes.

Reference book: The 10th chapter of MAVEN Combat-Xu Xiaobin

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Plug-in testing with MAVEN