WSO2 Test Automation framework use TestNG as its test underlying test engine. And the Surefire Plugin is used during the "test" phase of the build Lifecycle to execute the integration tests of a product
Debug maven forked Tests
By default, Maven runs your tests in a separate ("forked") process. You can use the maven.surefire.debug property to debug your forked tests remotely, like this:
mvn -Dmaven.surefire.debug
The tests will automatically pause and await a remote debugger on port 5005. You can then attach to the running tests using your IDE. If you need to configure a different port, you may pass a more detailed value. For example, the command below will use port 8000 instead of port 5005.
mvn -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -Xnoagent -Djava.compiler=NONE" test
Also you can debug tests by adding the following property to surefire plugin configuration section.
-Xms512m -Xmx1024m -XX:MaxPermSize=128m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006
By default, Maven runs your tests in a separate ("forked") process. You can use the maven.surefire.debug property to debug your forked tests remotely, like this:
mvn -Dmaven.surefire.debug
The tests will automatically pause and await a remote debugger on port 5005. You can then attach to the running tests using your IDE. If you need to configure a different port, you may pass a more detailed value. For example, the command below will use port 8000 instead of port 5005.
mvn -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -Xnoagent -Djava.compiler=NONE" test
Also you can debug tests by adding the following property to surefire plugin configuration section.
Debug product components
To debug product components while running integration tests, you have to follow a few steps.
1. Go to your product build location, usually the product distribution can be found at $PRODUCT_NAME/modules/distribution/target. The test framework extract the product distribution at the default build location to test module target directory before running test suites. Then extract the product distribution. And go to the bin directory.
2. Open wso2server.sh (unix) and wso2server.bat (in windows). Then edit the script file and put remote debug command generated through your favorite IDE into jvm system properties section.
In my case the jvm remote debug properties generated though my IDE is;
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005
Edit the script as follows
$JAVACMD \
$JAVACMD \
-Xbootclasspath/a:"$CARBON_XBOOTCLASSPATH" \
-Xms256m -Xmx1024m -XX:MaxPermSize=256m \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath="$CARBON_HOME/repository/logs/heap-dump.hprof" \
$JAVA_OPTS \
-Dcom.sun.management.jmxremote \
-classpath "$CARBON_CLASSPATH" \
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" \
-Djava.io.tmpdir="$CARBON_HOME/tmp" \
-Dcatalina.base="$CARBON_HOME/lib/tomcat" \
-Dwso2.server.standalone=true \
3. After editing server startup script, recompress the distribution and replace the product distribution at $PRODUCT_NAME/modules/distribution/target.
Now run the integration tests and execution, you will see that execution will be paused and awaits for remote debugger.
Happy debugging!!
No comments:
Post a Comment