Showing posts with label automation. Show all posts
Showing posts with label automation. Show all posts

Tuesday, June 28, 2016

Test Automation Architecture


Following three repos have been used to facilitate test automation for WSO2 products. Each component will describe in this post later.
  1. Test Automation Framework (git repo link - carbon-platform-integration)
  2. Carbon Automation Test Utils (git repo link - carbon-platform-integration-utils)
  3. Collection of all test suites and a test runner (git repo link - carbon-platform-automated-test-suite)

Test Automation Framework components

Architecture - AutomationFramework (2).png

Components related to TestNG is marked in dark-red colour

Automation framework engine

  • Automation Context builder - Process automation.xml given though test module and make all configurations available through Automation Context.

  • TestNG extension Executor -  Responsible for execution of internal/external extension classes in various states of the TestNG listeners.

Pluggable utilities to the test execution (TestNG)

There are several interfaces that allow you to modify TestNG's behaviour. These interfaces are broadly called "TestNG Listeners".  Test Automation Framework supports the execution of internal/external extension classes in various states of the TestNG listeners. Users can define the class paths in the automation.xml file under the desired TestNG listener states
Automation Framework uses Java reflection to execute classes. Users are expected to use the interface provided by the framework to develop external extension classes to be executed in the test. There are 5 interfaces provided by TAF for different TestNG listeners. Those interfaces have specific methods defined explicitly to be inline with the corresponding TestNG listeners. The interfaces are:
  • ExecutionListenerExtension
  • ReportListenerExtension
  • SuiteListenerExtension
  • TestListenerExtension
  • TransformListenerExtension

Automation Framework Common Extensions (Java)

This module consists of a set of default pluggable modules common to the platform. These pluggable modules can be executed in the test execution registering those in the test configuration file (automation.xml). TAF provides common modules such as the
  • CarbonServerExtension -  For server startup, shutdown operations of carbon server. And coverage    generation is also a part of this class.  
  • Axis2ServerExtension -  For axis2 server startup and shutdown. Facilitate backend for integration tests.
Also extensions module contain classes facilitate third party framework integration
  • SeleniumBrowserManager - Creates Selenium WebDriver instance based on the given browser configuration at automation.xml
  • JmeterTestRunner - Executes jmeter test scripts in headless mode and inject result to surefire test result reports.
Users can also add any platform wide common modules into the Automation Framework Extensions. Test specific pluggable modules should be kept in the test module side and those modules can also be used for the tests by registering it in the automation configuration file.

Automation Framework Utils (Java)

Utility components that provide frequently used functionality, such as sending SOAP and REST requests to a known endpoint or monitoring a port to determine whether it's available. You can add the Utils module to your test case to get the functionality you need. Some sample utilities are:
  • TCPMon Listener
  • FTP Server Manager
  • SFTP Server Manager
  • SimpleHTTPServer
  • ActiveMQ Server
  • Axis2 clients
  • JsonClients
  • MutualSSLClient
  • HTTPClient
  • HTTPURLConnectionClient
  • Wire message monitor
  • Proxy Server
  • Tomcat Server
  • Simple Web Server (To facilitate content type testing)
  • FileReader, XMLFileReader
  • WireMonitor
  • Concurrent request Generator
  • Database Manager (DAO)

Test Framework Unit Tests - Unit test classes to verify context builder and utility classes, depends on TestNG for unit testing.

Carbon Automation Test Utils


Carbon Platform Utils -  AutomationFramework.png


Common Framework Tests


There are integration test scenarios common to all WSO2 products. Implementing tests for those common scenarios in each product might introduce test duplication and test management difficulties. Thus, a set of common tests are introduced under the framework utilities module which can be used directly by extending the test classes.
e.g
  1. DistributionValidationTest
  2. JaggeryServerTest
  3. OSGIServerBundleStatusTest
  4. ServerStartupBaseTest

Common Admin Clients


This module consists of set of admin clients to invoke backend admin services together with supportive utility methods which are common for WSO2 product platform.
e.g
  • ServerAminClient
  • LogViewerAdminClient
  • UserManagementClient
  • SecurityAdminServiceClient

Common Test Utils


Frequently used test utility classes which depends on platform dependencies.
e.g
  • SecureAxis2ServiceClient
  • TestCoverageReportUtil - (To merge coverage reports)
  • ServerConfiurationManager (To change carbon configuration files)
  • LoginLogoutClient

Common Extensions


Consists of Pluggable classes allowing to plug additional extensions to the test execution flow. Frequently used test framework extension classes which are available by default, these classes use platform dependencies.

e.g UserPopulatorExtension - For user population/deletion operations

Platform Automated Test Suite


Builds a distribution containing all integration and platform test jars released with each product. It contains an ant based test executor to run the test cases in each test jar file. This ant script is based on TestNG ant task which can be used as a test case runner. The ant script contains a mail task which can be configured to send out a notification mail upon test execution. The PATS distribution can be used to run the set of tests on a pre-configured product cluster/distribution.


PATS - AutomationFramework.png

Saturday, June 22, 2013

WSO2 Test Automation Framework: How to debug product integration tests

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 


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

Edit the script as follows

$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!!