Running Unit Tests

Developers typically run Unit Tests through IDEs, not through the classic JUnit test runners. Unit tests can also be run through Maven - indeed, if you're not careful, Maven will run unit tests even when you don't want it. When tests are run through Maven, the Surefire plugin can produce various reports on the health of the unit test suite. In Financials 6, running the unit test suite must be done against a database populated with demo data from both the Financials and Rice datasets - ie, to run locally, you should run against a local satellite database.

With Financials 6's move to Maven, the optional KFS modules have been moved into separate KFS modules, and the core modules are together in one Maven module. To run tests for a single module, simply run the "mvn test" maven lifecycle command in the module where you'd like to run the tests (e.g., kfs/kfs-ar); or, alternatively, run any mvn lifecycle command (package, install) which depends on the test step without applying the -DskipTests command line option in that directory.

If you'd like to run the whole test suite, simply run "mvn test" from the root kfs pom. Note that running the entire suite can take over an hour locally.

The Financials product team has a continuous integration system, Jenkins, which runs the unit test suite. The tests are run each time a pull request is added. The outcome of the test can be determined based on a red X next to the pull request (failure) or green check (success).

The plan going forward includes increasing the size of the unit test suite as well as including more automated functional testing; it is also being considered how to adopt a microservices approach, which may split functionality out into separate projects - along with related tests.

Running a Single Unit Test

Running just a single unit test is typically accomplished through the IDE. Please consult IDE instructions on how to accomplish that.

Of course, you can run single unit tests through Maven as well. When you run maven, you need to specify the module on the command line. As an example:

mvn test -e -Dtest=org.kuali.kfs.module.ar.batch.CustomerInvoiceWriteoffBatchDigesterTest -pl kfs-ar

No Broken Windows

The tests are basically binary: green or red. They either all pass, or they don't. Normally projects developing with unit tests fix them as soon as they break, so most of the time 100% pass. This is the methodology that makes automated testing effective. It's much easier to maintain the tests if broken tests are fixed immediately. That minimizes the changes which need to be considered during troubleshooting, and minimizes further development that depends on buggy code. It's also an opportunity to make the test itself easier to maintain, and by eliminating bugs in production code it improves the productivity of the developers affected by that bug and acts as a form of communication between remote developers.