Difference between revisions of "Software Testing"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 33: Line 33:
:</pre>
:</pre>


The existence of the required Interface test class can be checked later by parsing of pom.xml (e.g with command line utility)
: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?)
* 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?)

Revision as of 09:35, 24 June 2010

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

Test Resources[edit]

Common Test Resources[edit]

  • Should be created together with SVM
  • Should be stored in one place (which one?)

Specific Test Resources[edit]

  • To be defined individually by each module and saved in src/test/resources

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?)
  • All other JUnit tests for a module should be presented in a separate test class. [optional]

Integration Tests[edit]

Technical Integration[edit]

Logical Integration[edit]

  • Functionality tests (JUnit)
    • According to functionalities desc in CoLab? To be defined together with SVM.
  • Selenium tests (GUI)
    • According to test scenarios in JIRA, like for PubMan

System Test[edit]

Manual testing of Solutions by GUI & SVM Groups

Bug Testing[edit]

Critical (regularly occurring) bugs should be identified together with SVN and tested with the specific Test (Selenium or JUnit), on hand of its nature.

Schedule[edit]

  1. Module Tests
  2. Integration Tests
    ...
  3. Bug testing

References[edit]