Difference between revisions of "Software Testing"
Jump to navigation
Jump to search
Kleinfercher (talk | contribs) (→Integration Tests: updated after meeting) |
|||
Line 38: | Line 38: | ||
=Integration Tests= | =Integration Tests= | ||
Integration tests need to be implemented only for services which have dependencies to other services. A new service will be introduced were the integration tests for our modules are implemented (Integration Test Service) | |||
Integration Tests should be performed for: | |||
# HTTP interfaces (REST, unapi, other) | |||
#: Different tools already exist which we can use (as mvn dependency or java code generator). | |||
* | #: Example in [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework_test.py python] | ||
#: Tests should be generic, therefore we could introduce a test.xml which provides the links for the interfaces to test (not static in source code). Thus testing a new interface should only demand entering the url in this test.xml | |||
# EJB interfaces | |||
==Test Process == | |||
* Check if the service can communicate to the required others (e.g. response code 200, AssertNotNull) [''required''] | |||
* Check if the outcome of a method is the specified, desired one (e.g. valid escidoc xml). [''optional''] | |||
* Test input should be valid and invalid parameters | |||
=System Tests= | =System Tests= |
Revision as of 14:50, 1 July 2010
Please Note: Work in Progress
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]
Integration tests need to be implemented only for services which have dependencies to other services. A new service will be introduced were the integration tests for our modules are implemented (Integration Test Service) Integration Tests should be performed for:
- HTTP interfaces (REST, unapi, other)
- Different tools already exist which we can use (as mvn dependency or java code generator).
- Example in python
- Tests should be generic, therefore we could introduce a test.xml which provides the links for the interfaces to test (not static in source code). Thus testing a new interface should only demand entering the url in this test.xml
- EJB interfaces
Test Process[edit]
- Check if the service can communicate to the required others (e.g. response code 200, AssertNotNull) [required]
- Check if the outcome of a method is the specified, desired one (e.g. valid escidoc xml). [optional]
- Test input should be valid and invalid parameters
System Tests[edit]
- Automated functional tests on solution level
- According to functionalities desc in CoLab? To be defined together with SVM.
- Manual functional tests by SVM group
- GUI tests
- Manual gui/ browser tests by GUI group
- Selenium tests (GUI)
- According to test scenarios in JIRA, like for PubMan
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.
- Check 'old' bugs for test candidates
- Specify criteria for new bugs becoming test candidates
Test Resources[edit]
- 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?)
- Specific Test Resources
- To be defined individually by each module and saved in
src/test/resources
- To be defined individually by each module and saved in
Schedule[edit]
- Identify existing tests
- Create appropriate, generic test resources
- Enhance module tests according to specification
- Implement integration tests according to specification
- Technical integration tests
- Logical integration tests
- ...
- Check and specify what system tests (manual tests) are necessary
- Identify and implement bug tests
Tools[edit]
- RESTClient - easy Java-based REST testing tool
- soapUI - the leading tool for SOAP and REST testing