Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 KFS 6, running the unit test suite must be done against a database populated with demo data - ie, to run locally, you should run against a local satellite database.

With KFS 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 KFS product team has a continuous integration system, Jenkins, which runs the unit test suite.  As of KFS 6, it will only run the module unit tests for code affected by a code change.  This is to say: if a commit was added to the system which only affected classes in org.kuali.kfs.module.purap, then Jenkins will run only the tests for the kfs-purap module.  This speeds up the continuous integration a great deal, which means that developers can get feedback from Jenkins pretty quickly if their commit has broken something important.

KFS's plan 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:

mvn test -e -Dtest=PreCommitSuite

Unit Testing Before Submitting a Pull Request

Please run the PreCommitSuite unit test before submitting a pull request to verify that your code changes do not break standards in the KFS project.  The PreCommitSuite has been specifically chosen to represent tests which enforce KFS standards and which run relatively quickly.

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.

  • No labels