Announcement: You can find the guides for Commerce 7.5 and later on the new Elastic Path Documentation site. This Developer Center contains the guides for Commerce 6.13.0 through 7.4.1.Visit new site

This version of Elastic Path Commerce is no longer supported or maintained. To upgrade to the latest version, contact your Elastic Path representative.

Unit testing

Unit testing

Elastic Path Commerce code in the core project is extensively unit tested using the JUnit testing framework. This test coverage provides a quick and effective way to detect bugs that may have been introduced while making modifications. When customizing Elastic Path Commerce, it is good practice to write JUnit tests for new or modified code and run all JUnit tests prior to committing changes. The majority of the JUnit tests in Elastic Path cover code in the ep-core project, where test coverage by line is approximately 70%. In addition, core JUnit tests find Spring configuration errors at build time, so you won't have to wait until the server starts up to find bugs such as duplicate bean names or XML format errors.

Running JUnit tests

JUnit tests can be run via Maven or from within the Eclipse development environment.

Running tests with Maven

JUnit tests in Elastic Path Commerce can be executed by running the following Maven tasks from the root of the project:

  • To run all JUnit tests:
    mvn install
  • To run all JUnit tests and JUnit integration tests:
    mvn install -Pwith-itests
  • To run an individual JUnit test:
    mvn install -Dtest=<test_class_name>
  • To run an individual JUnit integration test:
    mvn install -Dit.test=<test_class_name>

Maven will report the status of the tests in the command line. For example:

0:21:24 : -------------------------------------------------------
10:21:24 :  T E S T S
10:21:24 : -------------------------------------------------------
10:21:25 : Running
10:21:25 : Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.061 sec
10:21:25 : 
10:21:25 : Results :
10:21:25 : 
10:21:25 : Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

Maven creates an XML file during this process for each test that will include additional details about failing tests. The test output files can be found in <artifact_Id>\target\surefire-reports and the file names are composed of the package name and file name of the test case.

Running tests with Eclipse

JUnit tests can also be run from within Eclipse. To run an individual test case, right-click on the test file in the Package Explorer and select run as... -> JUnit Test. You can also run all tests in an entire project by right-clicking on the project in the Package Explorer and selecting Run As... -> Junit Test.

Note: Setting memory options in Eclipse

The default memory for launching applications in Eclipse is insufficient for executing all unit tests in the core project. You can increase the default memory settings by navigating to Window -> preferences -> Java -> Installed JREs -> Select your JRE -> Edit... and set your memory settings in the "Default VM Arguments" input box. The recommended setting is "-Xmx512m".

Creating unit tests

Adding a new unit test

The JUnit test case for a class is typically the name of the class with "Test" appended at the end. Test cases should be in the same package as the class they test so that they have protected access to the class's members. To avoid cluttering the production code with unit test classes, place unit tests in a "test" directory structure that mirrors the "main" source folder. For example, the Cortex JUnit tests are in the same package structure as the java code they are testing, but they are in the "test" folder.

Source Code Structure

Within the test case, a constructor is not required unless there is initialization that must be performed only once for the entire test case. A main method that runs the text UI or Swing UI is also not required as it is not used by the Eclipse JUnit runner the or Maven JUnit task.

Test cases in Elastic Path typically use the setup() method to instantiate the object tested by each test in the test case. The setup() method is also frequently used to configure any Jmock mock objects that are not specific to any one test.