Noctam/DWP/ACS Test Harness/Specifications/JIRA Issues/ACS Test Harness

ACS Test Harness

edit this panel Meetings 06/09/2021: Initial Workshop 01/10/2021: Current System Existing System CISSIM Command Line Tools User Docs PDSIM.odt PDSIM demo.odt PVTstub.odt simcertshowto.txt SIMD.odt Specifications JIRA Issues ACS Test Harness General Services CIS NPS Transactions DCI908 DCI913 DCI923 PDD Diary 2009: Week 1: 06/09 - 12/09 Week 2: 13/09 - 19/09 Week 3: 20/09 - 26/09 Week 4: 27/09 - 03/10 Notes

This issue represents the ACS test harness.

It will be necessarily high level at first; I expect to add sub-issues to go into more detail of any vertical slices which can be gleaned from the greater whole.

It has been raised as JIRA Issue FDACS-4565.

Background

In the olden days, an ACS 'stub' server was created which returned some hardcoded XML when prompted by a HTTP call. It was pretty basic, and didn't really test that much - in a nutshell, it could be used to ensure that the XML processing in ACS worked correctly, albeit with limited examples of that XML.

That functionality was taken and a 'CISSIM' python application was written which implemented and extended that, adding encryption using the appropriate keys and certificates, such that the encryption handling in ACS could be tested; it also added the choosing of different response files based on queries performed on the request, and it supported the replacement of particular data in the response XML - typically used to take the NINo from the request XML and inject it into the appropriate NINo fields in the response XML before returning it.

The CISSIM program supported DCI calls (SOAP calls using UTF-8 or ISO-8859-1 - ASCII-based charsets anyway), PDD calls (Strictly structured record data in EBCDIC, encoded into BASE64; the record definition is held separately) and NPC calls (SOAP / UTF8 again, but something that the original stub did not support).

More functionality was added to aid in getting the record structures for PDD calls / dialogs, acting as a logging proxy to CIS, etc, but that is outside the scope of this issue.

The program got distributed to various systems and modified in place to fix system-specific issues, and was generally not controlled.

The aim now is to create a managed, controlled version of the test harness which can be used to test ACS in all environments with all of the above specified functionality. This issue represents the work to achieve that aim.

Ask

We want a server application which can be run with specific configuration.

The server should be able to provide valid "live-like" responses for:

• DCI calls
• PDD calls
• NPC calls

The different calls should be identified by the path of the URL used in the HTTPS request.

We will need startup/shutdown scripts to make it easy to run.

Ultimately, this should be able to form part of the continuous integration of the ACS product - as such, we need a way of implementing this server as a docker image or similar, so that it can easily run by other developers and the gitlab build system.

Configuration

The configuration needs to support:

• PEM files providing certificates and private key for the server authentication handshakes.
• a library of XML documents to use as responses to calls from ACS
• a mechanism for determining which XML document to respond to a request with, including queries which can be performed on the request XML to test different use cases in the calling system
• a replacement mechanism where data in the response XML can be replaced with contextual data, including content or substrings of content from:
  • Literal values defined in the query
  • Static parameters defined in the configuration
  • Values retrieved from the request XML.
• Logging level and output

The server will require:

• Files containing response data for the various systems
• Record descriptors for the PDD requests/responses which need to be supported by the test harness

Deliverable

• A project containing all the source code for the new harness server
• A full set of unit tests with as much code coverage as is possible
• READMEs and documentation as appropriate to describe the usage and configuration of the server
• BASH Scripts to start and stop the server with any required command line options
  • These should support the -h or --help flags to indicate usage of the program
• Some form of docker deliverable (Dockerfile or docker-compose YAML file) which can be used to host the harness in a docker container.

Testing

To be defined