This section contains description descriptions and links to test and validation tools, which are for public use. Testing scenarios, test data, and test results are also listed. Information of a similar type available elsewhere is linked.
...
Conformity standards
In the EWP Network network, conformity standards are defined on various levels and with various means:
Formal specification of the EWP Network network architecture;
Formal specification of EWP network security protocols;
Formal specification of APIs for exchange of mobility data and supporting various mobility scenarios;
Examples of data records, use cases, and test scenarios;
Supporting documents explaining mandatory business requirements in a less formal way;
Validators that, on the one hand, define the data format , and format of requests and responses and, and on the other, provide tools for automatic validation.
...
Entry procedure with mandatory steps
to perform automatic validation tests;
to execute testing with the reference implementation, i.e., the EWP Dashboard;
The validation tests carried out by the EWP technical team as part of the acceptance procedure;
The registration process is when the mobility software is finally approved for production use.
The conformance validation is facilitated by the DEMO environment, which can be used by the EWP technical team, but also the mobility software providers , upon request. The Dashboard development team maintains test installations used for testing with the reference implementation.
There are various meeting places and fora forums where providers can discuss technical issues. They also play an important role in clarifying standards and facilitating the development of standards-compliant software:
Regular meetings of the technical community of mobility software providers on the Infrastructure Forum, where all technical issues are thoroughly discussed, new APIs introduced, and their specifications elaborated.
Technical workshops for the providers.
Discussions in GitHub issues are available to the public.
...
EWP
...
network Validation tools
There are three groups of tools for automatic testing of the EWP APIs:
...
XML Schema Validator helps developers with writing EWP XML documents. It should be possible to validate any XML document described in all RELEASED, DEPRECATED, and OBSOLETE specifications (plus, perhaps, some of the DRAFT ones).
XML Schema Validator can be found on the DEV Registry Service website in the XML Schema Validator section (similarly in the PROD Registry). A developer can copy any produced XML document, including the manifest file, and validate its compliance with the XSD schema.
Documents which that do not pass the test should not be sent via the EWP Networknetwork. Implementations have the right to reject incorrect documents.
...
API Validator is a tool that helps developers to determine if their implementation conforms to the EWP specifications. It plays an extremely important role in the development process. The validator is integrated with the EWP registry and available in on GitHub. It can be used either in a local environment or on-line online from the DEV Registry Service website.
A developer can install the registry in their local environment and test their development installation, even before contacting the EWP Network network administrator. There is a package in GitHub which that can be downloaded and installed in the local environment. The README-local-registry.md document describes the possible testing options. The simplest option, Scenario 2: Using web validator, is described in it.
If a developer would like to learn about other possibilities of running the Validator, test their installation registered in the development Registry, or test themselves their implementation of another partner in the network, they should read EWP-Validator-HOWTO.txt describing all validation options.
If a developer’s installation is already publicly available, they can use the on-line online Validator, which is located on the Dev Registry Service website in the Manifest Importer Status section, to test public APIs. It doesn't have access to confidential data, so you they will not be able to test APIs like omobilities or LAs.
IIA Hash Validator
This validator checks the hash of the cooperation conditions present in the IIA to get response.
IIA Hash Validator can be found on the DEV Registry Service website in the IIA Hash Validator section (similarly in the PROD Registry). A developer can copy any <iia> element obtained from the IIA get response, and validate if the <conditions-hash> element contains a proper value.
Source The source code in Java used for hash calculation and validation is posted in the GitHub repository. It can be used by Java developers in their solution. Other developers can grasp the idea by reading the code.
...
The DEMO testbed is a set of online services. Test installations of a student information system with the EWP connector and the mobility client, with the most recent versions of IIA and LA APIs, have been set up at the University of Warsaw.
The DEMO testbed is only available in the EWP DEV Networknetwork. This testbed contains the following applications:
...
These applications are used by the team from the University of Warsaw for testing EWP scenarios with other providers. Write to ewp-tech@lists.erasmuswithoutpaper.eu to schedule the test session.
Teams which that would like to test by themselves can get credentials upon request.
...
There is a separate document, DEMO Testbed. User Guide, which explains how the testbed operates , how to prepare test data and run tests. The current version of the user guide describes Interinstitutional Agreements inter-institutional agreements (part I) and Learning Agreements learning agreements (part II), but new chapters will be added with description descriptions of other processes, like nominations and Transcript of Records.
Having access to their own installation and the DEMO testbed installation, a developer can test full scenarios, both on the server and client sides, which could not be possible with the validators. It is recommended to to run scenarios stored in GitHub repositories for particular APIs.
It is also possible to use DEMO applications for exporting sample data to build unit tests of developers’ own software. LAs can be easily exported from the admission system in a raw XML format. Transcript Transcripts of Records can be exported from the student’s portal (in raw XML and in PDF).
...
They are written in the Gherkin notation. They are used by the EWP team for acceptance testing with the reference implementation. They may also be used by any development team for bilateral testing, inside local systems with their own installations, in the DEV network with any partner, or from within the DEMO testbed.
...
Obligations of providers before joining the EWP
...
network
The procedure of joining the EWP Network network for both groups of providers is described in detail in the Joining the EWP Networknetwork section of the IT Service Catalogue. In particular:
The provider MUST install and test its mobility software in the DEV network and test it.
The provider MUST perform automated self-tests with the validators.
The provider MUST test with the reference implementation. The EWP technical team will go through the testing scenarios as described in GitHub.
After successful testing, the provider may enter the production network. Only APIs that were tested can be included in the manifest file. When the provider would like to declare endpoints for new processes, they need to undergo the testing with the reference implementation.
...