Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 10 Next »

Overview

Documents the approach to functional/integration testing for the application REST services layer.

Coverage

These service are currently covered by REST integration testing.

  • Security Service
  • Metadata Service
  • Content Service
  • History Service
  • Project Service

Complete coverage would address each mode of use of each method call of each service, and combinations of calls across them, as well as any ad hoc test cases for identified errors not covered by existing test cases.

Coverage Definition

The attached spreadsheet formally defines REST service layer coverage from an integration testing perspective. 

Assumptions

  • A dev database exists that is loaded with exactly the sample "full" data from the config/ project.
  • Any changes made are reverted to initial conditions so all tests can assume identical initial conditions
  • A server built using the latest code is deployed to the URL specified in the base.url property of the config file used to run the integration tests.
  • The server is configured to use "default" authentication in which "guest" and "admin" users can be authenticated with any password (and the auth token matches the usernames)

Coverage is defined in a multi-dimensional matrix that takes into account the services, the methods of the services, and the modes of use of the services (including normal use, degenerate use, edge case use, and role check). NOTE: in many cases there are many "normal" modes of use which may extend the number of columns in the spreadsheet.  For example, methods that take optional parameters (e.g. Pfs).

The following sample coverage spreadsheet is the current coverage definition.

Organization

Integration tests are organized under the integration-testing project.  Looking through the Java packages, you should find a "org.ihtsdo.otf.ts.test.rest" package that defines a number of test classes that represent the coverage spreadsheet.

Generally each column of each tab of the coverage spreadsheet is represented by a single testing class, where each row within that column corresponds to a particular method of that testing class.  The coverage spreadsheet defines both the class names used to implement tests as well as the method names (so they can be easily cross referenced).

The test names themselves are "test cases" that are organized into "test suites" according to the structure of the spreadsheet.

For each test suite and test case, there should also exist a documentation page in this wiki.  A test suite is a collection of test cases and a test case is a "script" detailing the actions involved and the expected outcomes with any other needed information.

Integration Test Suites

Test suites are organized by spreadsheet tab.

Degenerate Use Test Automation

For repetitive testing of degenerate use of methods with null and empty values, a class DegenerateUseMethodTestHelper is provided.

To use the degenerate test helper:

 

For repetitive testing of degenerate use of methods with null and empty values, a class DegenerateUseMethodTestHelper is provided, which includes two static methods

  • DegenerateUseMethodTestHelper(Object, Method, Parameters, ExpectedFailures)
  • DegenerateUseMethodTestHelper(Object, Method, Parameters)

where:

  • Object:  The service client undergoing testing
  • Method:  The method of the service client to be tested
  • Parameters:  An object array of values that that produce successful invocation of the method
  • ExpectedFailures:  An ExpectedFailure array specifying the degenerate behavior for each parameter.  
    • EXCEPTION,
    • SKIP,
    • NONE,
    • LONG_INVALID_NO_RESULTS_NULL_EXCEPTION,
    • STRING_EMPTY_EXCEPTION_NULL_EXCEPTION,
    • STRING_EMPTY_EXCEPTION_NULL_NO_RESULTS,
    • STRING_EMPTY_EXCEPTION_NULL_SUCCESS,
    • STRING_EMPTY_NO_RESULTS_NULL_EXCEPTION,
    • STRING_EMPTY_NO_RESULTS_NULL_NO_RESULTS,
    • STRING_EMPTY_NO_RESULTS_NULL_SUCCESS,
    • STRING_EMPTY_SUCCESS_NULL_EXCEPTION,
    • STRING_EMPTY_SUCCESS_NULL_NO_RESULTS,
    • STRING_EMPTY_SUCCESS_NULL_SUCCESS,
    • NO_RESULTS,

Example:

SecurityClientRest service = new SecurityClientRest(ConfigUtility.getConfigProperties());
 
// use reflection to get the desired method
Method method =
        service.getClass().getMethod(
			"authenticate", 								// method name and parameters
			new Class<?>[] {String.class, String.class});	// i.e. SecurityClientRest.authenticate(String username, String password)
 
// specify the valid parameters
Object[] parameters = new Object[] {
        new String("name"), new String("password")			// valid parameters that when passed to method produce successful outcome (e.g. authentication)
    };
 
// call the helper
DegenerateUseMethodTestHelper.testDegenerateArguments(service, method,
        parameters);

 

 

References/Links

 

  • No labels