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 Page History

« Previous Version 4 Current »

Overview

The integration-test module contains test to verify the correct behavior of CPS/NCMP.

It's has tests to check both the functional and performance aspects of the software.

The packages are set up in a way to separate these core responsibilities.

To execute the tests we can run the individually in our IDE or all of them together during the build phase (like mvn clean install)

Base classes

The CpsIntegrationSpecBase class contains the required dependencies for the integration tests.
The common services are autowired so the actual classes will be used in the tests instead of mocks (except for the DMI Plugin).
Basic utility function are also present in the class like registering/removing CM Handles.

The FunctionalSpecBase class contains common logic to initialize data for the functional verification of CPS/NCMP.
This class also extends the CpsIntegrationSpecBase class.

The base lasses in the performance package also extending the CpsIntegrationSpecBase class


Data Set-up

The methods to set up data are defined in the base classes like registering cm handles:

        registerCmHandle(DMI1_URL, 'ch-1', NO_MODULE_SET_TAG, 'p1')

        
These methods must be called in each Spec file's setup method to add data to the test container. The developer must pay attention to clean up the test data after each case in the tests!

We also have to set up relations between cm handle ids and module names if we want to get data using the DMI Plugin.

        dmiDispatcher1.moduleNamesPerCmHandleId['ch-1'] = ['M1']

Use of Dispatchers

NCMP frequently interacts with the DMI Plugin to perform operations on the data/models. To mimic this behavior the integration tests are using a feature of MockWebServer to mock interactions with the DMI.
It has two main parts: a dedicated mock server and a dispatcher which has hardcoded endpoints (each with a specific response to it).
The configuration of the mock server is fairly straghtforward: we just have to create an instace of it and pass the feature-specific dispatcher to it.
And also the URL for the DMI must be created with the server and port values of the mock server.


        MockWebServer mockDmiServer1 = new MockWebServer()
        mockDmiServer1.setDispatcher(dmiDispatcher1)
        mockDmiServer1.start()
        DMI1_URL = String.format("http://%s:%s", mockDmiServer1.getHostName(), mockDmiServer1.getPort())


        
In the Dispatcher class we must override the dispatch method to define the behavior of the class like so:

    ...
        // get module references for a CM-handle
        case ~'^/dmi/v1/ch/(.*)/modules$':
            def cmHandleId = Matcher.lastMatcher[0][1]
            return getModuleReferencesResponse(cmHandleId)
        ...


Here in a swith case we define the URL of each endpoint we want to mimic and the path of the incoming request will be matched agains each case (based on a regepx) we defined then the closest match's code block will be executed.
We can define wildcards to prepare for random path variables with this expression: '(.*)'.

To simulate the DMI not being available, the boolean isAvailable may be set to false for the dispatcher object. In this case the mock server will always respond with 503 Service Unavailable.

  • No labels