Software Testing

This page will describe the testing approach for the services and solutions developed at the MPDL.

Module Tests

• Interface Tests should check all methods in the modules interface. [required]
  • Class Name convention:

src/test/java/<name_of_module_interface>InterfaceTest.java

example: src/test/java/CitationStyleHandlerInterfaceTest.java

• • The class should be explicitely declared in the module pom.xml

...

<plugin>

<artifactId>maven-surefire-plugin</artifactId>

<configuration>

<skip>false</skip>

<includes>

<include>**/CitationStyleHandlerInterfaceTest.java</include>

<!-- possible other test classes -->

<include>**/TestCitationStylesSubstantial.java</include>

</includes>

</configuration>

</plugin>

...

The existence of the required Interface test class can be checked later by parsing of pom.xml (e.g with command line utility)

• How to define scope of parameter values of tested interfaces ??? (e.g. dataacquistion, test all fetching formats for all sources? is one exemplary source enough?)

• Test exception handling on the different types of errors (e.g. for levels: fatal, errors, warnings) ???

• All other JUnit tests for a module should be presented in a separate test class. [optional]

Integration Tests

i.e. SOA services interaction via different module interfaces

• REST interfaces
  • Can be tested with: https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework_test.py ?
• EJB interfaces
• System behavior by service malfunction
• Selenium tests (GUI)
  • According to test scenarios in JIRA, like for PubMan

Solution Tests

1. Functional tests on solution level
   • According to functionalities desc in CoLab? To be defined together with SVM.
2. Manual functional tests by SVM group
3. Manual gui/ browser tests by GUI group

Bug Testing

Critical (regularly occurring) bugs should be identified together with SVM and checked with a appropriate test (Selenium or JUnit), on hand of its nature.

1. Check 'old' bugs for test candidates
2. Specify criteria for new bugs becoming test candidates

Test Resources

1. Common Test Resources
   • Should be created together with SVM (item with full md, previously critical items etc.)
   • Should be stored in one place (which one?)
2. Specific Test Resources
   • To be defined individually by each module and saved in src/test/resources

Schedule

1. Identify existing tests
2. Create appropriate, generic test resources
3. Enhance module tests according to specification
4. Implement integration tests according to specification
   • Technical integration tests
   • Logical integration tests

   ...

5. Check and specify what system tests (manual tests) are necessary
6. Identify and implement bug tests

Max Planck Digital Library

Service-Oriented Architecture

Representational State Transfer

Enterprise JavaBeans

Graphical User Interface

Error Management and Project Management Software

Collaboration Laboratory

Support Vector Machine