Web-service testing

This page collects information about testing of the ETICS web-service.

Unit tests

They test basic functionality, they do not require any infrastructure (like data-base or tomcat). Unit tests are stored in the main component and are executed during the remote build. Technically it is a set of JUnit tests (JUnit 3.8.1).

• component: org.etics.build-system.webservice
• sources in: /test
• execute locally: ant test.report
  It will produce JUnit test report in directory: /build/testReports
• execute remotely: automatically during every every remote build using JUnit plugin.
  TODO has to be checked again after the plugin is moved to production.
• scope of tests:
  • WebServiceUnitTests - a test suit that combines all tests into one start point. This test is actually called by the JUnit runner.
  • ObjectManagerTest - tests creation of an object from a map. It is a crucial functionality used for every web-service method.
  • OperationMapperTest - tests mapping between role list and operation list. Functionality used only in configuration web-application.
  • VersionWrapperTest - tests configuration version comparator. Functionality used for resolving dynamic dependencies when locking.

• Status on 10 March 2008: 18 tests, all complete successfully

Functional tests

Functional tests check the final web-service functionality that is available for the clients. They call methods from the web-service using completed SOAP protocol - they act in exactly the same way as command line client or configuration web-application.
In order to run those tests a complete ETICS web-service stack has to be installed and available.

Functional tests are implemented as a Java application using JUnit 3.8.1 framework.

• component: org.etics.build-system.webservice-testsuite
• sources in: /src
• execute locally: ant -DtestSuite.configFileLocation=testConfigFile.properties test
  Preconditions:
  • A valid host-certificate has to be available.
  • A valid trust store has to be available.
  • ETICS web-service has to be installed and running.
  • Provided host-certificate must be registered in the ETICS data-base.
  • testConfigFile.properties has to be generated with paths to host-certificate, trusted store and service URL (a template is available in /config/template/eticsBuildSystemWSTestSuiteConfiguration.properties).
• execute remotely: not automated. Available ETICS configuration build tests but does not execute them.
• scope of tests:
  • Configurations:
    • Creating, deleting, cloning and editing.
    • Escaping special characters - like single quotes (')
  • Locking:
    • Changing status to locked without calling proper WS method.
    • Modifying or removing locked configuration.
    • Cloning locked configuration.
    • NOTE: lockConfiguration method is not tested, all locking-test require a predefined locked configuration in data-base
  • Messaging subsystem (used for multi node tests):
    • Setting and getting messages.
  • Modules (read-only tests):
    • getProject
    • listProjects
    • getModule
    • getComponent, getProjectComponent, getSubsystemComponent
  • Roles: add, delete.
  • Stress test: call getConfigurationStructure from 2 threads
  • Submissions:
    • User requirements validity - requirements are proper filtered.
    • Submitting to a non available platform.
    • NOTE: successful submission is not tested.
  • Transaction (used in local editing):
    • Creating objects (project, subsystem, component, configuration).
    • Adding configuration dependencies.

• Status on 12 March 2008: 96 tests, 31 fails when running with no certificate (as expected),

Open issues

Unit tests: testing data-base module

Web-service bases on DAO design-pattern where all functionality related to data-base is encapsulated in one single class - DaoDB. This class simply generates SQL queries and sends them directly to a data-base. In order to test it a valid data-base is required.

There is a test-case called DaoDBSQLQueryTest located in the main module (org.etics.build-system.webservice). It tests all methods from DaoDB checking if all generated SQL queries have proper syntax and can be executed on the backed data-base. The data-base connection is described by 3 extra parameters that have to be delivered to this test-case in form of Java system properties (the test fails if any of those parameters is not available):

1. DaoDB.host - data-base host name, for instance etics-test.cern.ch.
2. DaoDB.user - data-base user name.
3. DaoDB.password - data-base user password.

Test cannot be run automatically during the build as it requires some infrastructure. It cannot be executed from other module as it tests private web-service functionality that is not available through WSDL interface. Still it is very useful (and relatively easy) to run it locally

• Status on 10 March 2008: 74 tests, all complete successfully when running using MySQL data-base runing on etics-test.cern.ch

Issue: How to automate this test?

-- TomaszKokoszka - 10 Mar 2008