Software Testing

From MPDLMediaWiki
Jump to navigation Jump to search

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

Module Tests[edit]

  • 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[edit]

i.e. SOA services interaction via different module interfaces

Solution Tests[edit]

  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[edit]

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[edit]

  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[edit]

  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

References[edit]