Building JUnit test Packages with Jython

The JUnit test framework is used by more and more development teams. Thanks to a variety of test-fixture modules, you can now test almost every component that makes up any Java application. In fact, almost the entire secondary market seems to have been built around Junit. The Cactus, Jfcunit, Xmlunit, DbUnit, and httpunit modules are free for developers to test applications. As the complexity of the system increases and there are so many tools to use, there is no reason not to rely on unit testing.

However, developers are more than just programmers. We interact with the user to fix bugs and identify requirements. We attend meetings and make telemarketing calls. We complete some (sometimes all) quality assurance functions. Since there are so many responsibilities, it is natural to want to automate as much as possible. Because a good team (among other things) will do a lot of testing, people who want to automate different development processes will often study this area in detail.

Automated Unit Testing

There are a number of ways to automate the positioning and execution of all project test cases. One solution is to use Ant's junit tasks together with embedded fileset tasks. This allows you to include and exclude files in a specific directory (based on the file name style). Another option is to use a feature of Eclipse, which specifies the directory in which all tests are located and executed. The previous option provides the flexibility to filter running tests (and since it is a pure headless (headless) Java application that can run almost everywhere), and the latter option can debug a "dynamic" package. Is it possible to combine the strengths and flexibility of both approaches?

With the Python programming language Java Platform Implementation-Jython, the answer is loud "Yes!" "(If you are unfamiliar with Jython, you should add this knowledge before proceeding with this article, please refer to later resources for more information.) With the power and elegance of the Jython, you can maintain a location file system, search for a class that matches a style, and script a dynamically compiled JUnit TestSuite class. This TestSuite class, like all other statically defined classes, can be easily debugged with a favorite debugger. (the example used in this article assumes that you are using the Eclipse IDE, but the techniques I describe here do not have to be modified to work with most other Ides.) ）

When making any design decisions, you must weigh the impact of the choices and decisions you make. Here, in order to get the ability to debug dynamically generated test packages, additional complexity must be added. However, this complexity is mitigated by Jython itself: Jython is well tested and well supported, and is open source. Also, Python is increasingly becoming the de facto standard for object-oriented, platform-independent programming. For both of these reasons, the risk of adopting Jython is minimal, especially as it provides the benefit of unmatched flexibility in creating and debugging dynamically generated JUnit TestSuite classes.

If the use of Jython is the primary consideration, it can also make progress in solving the original problem even if it is not used. Without Jython, you can use a Java property file to store a set of classes, directories, and packages to add or exclude tests in a package. However, if you choose to use Jython, you can use the entire Python language and runtime to resolve the problem of which tests you choose to perform. Python scripts are much more flexible than Java property files, and are limited by your imagination.

The seamless integration of Jython with the Java platform enables the creation of statically defined, dynamically constructed TestSuite classes. There are a lot of tutorials about JUnit, but look at the following two lines of code for review. Listing 1 is an example of a statically constructed TestSuite class (This example is taken from Junit:a Cook's Tour and links to other JUnit resources See Resources):

Listing 1. Static definition TestSuite

public static Test suite() {
　　 return new TestSuite( MoneyTest.class );
}

Listing 1 shows that TestSuite is made up of class instances of the Test class. This fixture module fully utilizes this. To analyze the code for this tool, download the sample JAR file for this article from resources. This document contains two files: Dynamictestsuite.java and getalltests.py, a JUnit test module that dynamically generates TestSuite with Phthon scripts, which is a search for files that match a particular style. Python script. Dynamictestsuite.java uses getalltests.py to build TestSuite. You can modify the getalltests.py to better suit your project needs.

Understanding Test Fixture Modules

How does the code work? First, assign getalltests.py to get a set of Test classes to execute. Then, use the Jython API to extract the list from the Python run-time environment. Then use the Java Reflection API to build the class instance of the String object in the list that represents the Test class name. Finally, Test is added to the TestSuite with the JUnit API. The interaction of these four libraries can achieve your goal: dynamically constructed TestSuite can be run as statically defined.

Take a look at the JUnit Suite list in Listing 2. It is a TestCase that exposes the public static TestSuite Suite () method signature. The suite () method called by the JUnit Framework calls Gettestsuite (), and Gettestsuite () calls Getclassnamesviajython () to get a set of String objects, each of which represents a part of the package The TestCase class.