Automated Testing
OpenEMR has an automated test suite designed to help ensure that the code does what it's supposed to and that new features do not break existing features. (note that this thing has been broken/not used for some time now)
How to run the tests
You can run the test suite in two ways. You can run it manually on your own code while you are developing code and associated tests. The automated test suite will also be run each time a commit is made to the git repository.
Manually running the test suite
To run the test suite, you can run the http://www.phpunit.de/ phpunit] command. It will create and drop a database named "openemr_test_suite" that it uses for testing purposes. In order to do that, it needs your mysql root password, which you can pass in using the environment variable "EMR_ROOT_DATABASE_PASSWORD". You can set that at the same time as you run phpunit, so your command may look something like this:
EMR_ROOT_DATABASE_PASSWORD=mysql_root_password phpunit --verbose
Viewing the tests run by the continuous integration server
Each time a new commit is made to the source code repository, a continuous integration server runs the test suite on the new code base. The results of that can be viewed at openemrqa.mooresystems.com
How to add tests
The test suite consists of a collection of PHP classes defined in the "Tests" directory of the distribution. All filenames ending in "Test.php" are examined for test classes which are run under PHPUnit. For more information on how to write test classes, please see the PHPUnit documentation, or use some of the existing test classes as examples.
Writing testable code
There are a few "rules of thumb" that may help you write code that can more easily be tested.
- Code in classes tends to be easier to test than procedural code directly in the top level PHP files. This is because you can load up the class, run methods on it, and compare the results to the expected results.
- Methods that return values tend to be easier to test than methods that directly print HTML. If you have a method that prints HTML, you can use the "ob_start()" and "ob_get_clean()" methods to capture the output and compare it to the expected results
- Classes with fewer dependencies tend to be easier to test. This prevents you from having to mock up dependencies for the class to use.
