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 smile

  • 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

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2008-04-02 - TomaszKokoszka
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ETICS All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback