Running Individual Tests

When you debug issues, we recommend executing a specific test through Maven on the command line to save time and for convenience. This topic describes how to use commands to run and remotely debug single unit tests or integration tests.

note

All commands in the examples open remote debugging on port 8000.

Surefire Unit Tests

The Maven Surefire plugin is used to run unit tests of an application. For more information, see the Maven Surefire Plugin documentation.

Running a single test

To run a single test using the Maven Surefire plugin, use the following command:

mvn test -Dtest=<TEST_CLASS_NAME#TEST_METHOD_NAME>

Debugging a single test

To debug a single test using the Maven Surefire plugin, use the following command:

mvn test -Dmaven.surefire.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000" -Dtest=<TEST_CLASS_NAME#TEST_METHOD_NAME>

Failsafe Integration Tests

The Maven Failsafe plugin is used to run integration tests. For more information, see the Maven Failsafe Plugin documentation.

Running a single integration test

To run a single Maven Failsafe plugin integration test, use the following command:

mvn verify -Dit.test=<TEST_CLASS_NAME#TEST_METHOD_NAME>

Debugging a single integration test

To debug a single Maven Failsafe plugin integration test, use the following command:

mvn verify -Dmaven.failsafe.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000" -Dit.test=<TEST_CLASS_NAME#TEST_METHOD_NAME>

Failsafe Cucumber Tests

The Maven Failsafe plugin also supports using Cucumber.

Running a single Cucumber test

To run a single Cucumber test, use the following command:

mvn verify -Dcucumber.options="src/test/cucumber/com/elasticpath/cucumber/<FEATURE_FILENAME>"

Debugging a single Cucumber test

To debug a single Cucumber test, use the following command:

mvn verify -Dmaven.failsafe.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000" -Dcucumber.options="src/test/cucumber/com/elasticpath/cucumber/<FEATURE_FILENAME>"

Failsafe Selenium Tests

The Maven Failsafe plugin also supports using Selenium.

1. Start the Selenium standalone Chrome docker image:

   docker run -d \
   -p 4444:4444 \
   -p 7900:7900 \
   -e SCREEN_WIDTH=1920 \
   -e SCREEN_HEIGHT=1080 \
   -e SCREEN_DEPTH=24 \
   --shm-size=2g \
   selenium/standalone-chrome:latest
   

   note

   On a Mac M1 processor, replace selenium/standalone-chrome:latest with seleniarm/standalone-chromium:latest in the command above.

   note

   If using a Docker service that is not Docker Desktop, add --add-host=host.docker.internal:host-gateway before selenium/standalone-chrome:latest in the command above.

2. Start the following locally:

   • ActiveMQ
   • Cortex
   • Search Server
   • Batch Server
   • Integration Server
   • Commerce Manager

   note

   Use the following command to start Commerce Manager:

   mvn clean package cargo:run -PenableUITests
   

Running a single Selenium test

To run a single Selenium test, change to your extensions/cm/ext-cm-modules/system-tests/selenium folder and use the following command:

mvn verify -Premote \
-Dselenium.session.browser=remote_chrome \
-Dremote.web.driver.url=http://localhost:4444/wd/hub \
-Dselenium.session.baseurl=http://host.docker.internal:8081/cm \
-Dep.export.cm.host=host.docker.internal \
-Dep.import.cm.host=host.docker.internal \
-Dexport.db.connection.host=localhost \
-Dexport.import.db.schemaname=<DB_SCHEMA> \
-Dexport.import.db.connection.username=<DB_USERNAME> \
-Dexport.import.db.connection.password=<DB_PASSWORD> \
-Dsearch.host.url=http://localhost:8082/searchserver \
-Dcucumber.options="src/test/resources/com.elasticpath.cucumber/<FEATURE_FILENAME>"

note

Make sure to replace the <DB_SCHEMA>, <DB_USERNAME>, and <DB_PASSWORD> placeholders in the command above.

Debugging a single Selenium test

To debug a single Selenium test, change to your extensions/cm/ext-cm-modules/system-tests/selenium folder and use the following command:

mvn verify -Premote \
-Dselenium.session.browser=remote_chrome \
-Dremote.web.driver.url=http://localhost:4444/wd/hub \
-Dselenium.session.baseurl=http://host.docker.internal:8081/cm \
-Dep.export.cm.host=host.docker.internal \
-Dep.import.cm.host=host.docker.internal \
-Dexport.db.connection.host=localhost \
-Dexport.import.db.schemaname=<DB_SCHEMA> \
-Dexport.import.db.connection.username=<DB_USERNAME> \
-Dexport.import.db.connection.password=<DB_PASSWORD> \
-Dsearch.host.url=http://localhost:8082/searchserver \
-Dmaven.failsafe.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000" \
-Dcucumber.options="src/test/resources/com.elasticpath.cucumber/<FEATURE_FILENAME>"

note

Make sure to replace the <DB_SCHEMA>, <DB_USERNAME>, and <DB_PASSWORD> placeholders in the command above.

View the running test

To see what is happening inside the container, connect to http://localhost:7900/?autoconnect=1&resize=scale&password=secret.

JPQL Query Test

A special integration test exists in the ep-core-itests module that can be used to test JPQL queries. This test supports both interactive and non-interactive modes.

To use it in non-interactive mode, do the following:

1. Open the com.elasticpath.test.db.JpqlQueryTest#testJpqlQuery method in your development environment.
2. Change the query string to the JPQL query that you want to test. You can also change the query result assertions.
3. In your terminal window, run mvn verify --pl :ep-core-itests -Dit.test=JpqlQueryTest#testJpqlQuery from the root of the Self-Managed Commerce source.

To use it in interactive mode, do the following:

1. Remove the @Ignore annotation from the com.elasticpath.test.db.JpqlQueryTest#developJpqlQueryWithUI method.

2. In your terminal window, run mvn verify --pl :ep-core-itests -Dit.test=JpqlQueryTest#developJpqlQueryWithUI from the root of the Self-Managed Commerce source.

3. After a few seconds, a console window will appear:

   

4. To execute a JPQL query, use the runQuery command by typing it at the bottom of the white console window:

   runQuery("SELECT psku.productInternal.code, psku.skuCodeInternal"
                       + " FROM ProductSkuImpl psku")
   

5. Press Command-R or use the "Script" --> "Run" menu item to run the query.

6. The query result will be displayed in the yellow console window.

7. When you are done, press Command-Q or use the "ForkedBooter" --> "Quit ForkedBooter" menu item to close the console window.

note

By default, the database used by this test is only populated with basic data by the SimpleStoreScenario and ProductsScenario. To populate the database with more data, add additional scenarios within the com.elasticpath.test.db.JpqlQueryTest#setUpDb method.

Webapp Smoke Tests

The webapp-smoketest module contains special Cucumber and unit tests that verify the functionality of the webapps. The Self-Managed Commerce webapps are first started using Cargo, and then the tests make various requests against the webapps to ensure that they are behaving as expected.

One of these tests is com.elasticpath.smoketests.ApplicationStartupTest#testCortexSplitPackages, which looks for OSGi split packages. Split packages is a situation where the same Java package is exported by multiple bundles. This can be a dangerous situation because the application behavior can change depending on which bundle the package was imported from. It can also cause ClassCastException exceptions in some cases.

This test does the following:

1. Reads the split packages from the URL specified in the cortex.split.packages.path property in the test.properties file.
2. Ignores bundles that are contained in the allowed.same.bundle.split.packages property in the test.properties file.
3. Ignores packages where the same bundle exports multiple versions of the package.
4. Fails the test if a package is exported by more than one bundle. However, different exceptions are thrown depending on whether the bundles export different package versions or not:
   1. If the bundles export different package versions, the test will report that The package %s is exported by more than one bundle. This is almost always a problem.
   2. If the bundles export the same package version, the test will report that The package %s is exported by more than one bundle. The package versions are not the same. This might be acceptable in some circumstances, if this is intentional.

If split packages are detected, the ideal solution is to remove one of the bundles from OSGi. This is usually done by removing dependencies from the ext-cortex-webapp/pom.xml. If the split package situation is intentional, add one of the bundles to the allowed.same.bundle.split.packages property in the test.properties file.