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.
...
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:
Code Block |
---|
cd module mvn test -e -Dtest=PreCommitSuite |
Unit Testing Before Submitting a Pull Request
...
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.