OpenTest
[ JUN - AUG 2022 ]Development, standardization and automation of chained tests. Creation of a web interface to have a global view on the generated reports.
ROLE : Web Integrator
CLIENT : For FM Logistic Phalsbourg
At the end of my third year at INSA Lyon engineering school, I had the opportunity to complete my internship at FM Logistic, where I was able to develop my skills and build strong friendships.
With the support of my mentor Nicolas EISMANN, who acted as tech lead and introduced me to all the technologies used within the company, Denis SCHUVER as the technology manager who answered all my questions with humor, and other passionate colleagues like Arnaud JACQUILLARD, a Talend developer, and Matthieu REICHERT, the product owner whose enthusiasm and managerial experience truly made this internship both enriching and enjoyable.
Concept
The project’s goal was to automate the generation of test reports through Jenkins. At the start of the API creation process, a developer builds Postman test collections. Then, other developers implement the API while continuously checking on Jenkins whether the tests pass or fail. This workflow follows the Test Driven Development (TDD) methodology.
Technical Stack
- Postman: Writing tests in JavaScript.
- NodeJS: Scripts that execute Postman collections on Jenkins.
- Jenkins: Automates the execution of NodeJS scripts.
What Makes OpenTest Different from Other API Testing Tools?
- Postman collections can be run in parallel.
- Stress tests can be performed.
- If a test fails but your manual checks appear correct and rerunning tests takes too long, you can re-execute all verifications from the last test run on the Jenkins job with a single click!
- Postman tests are standardized for easy use. Test templates are available for both synchronous and asynchronous requests.
The Application in Action
On the Jenkins job page, click the “HTML Report” section to access OpenTest’s web interface.
For each report, you can see the name of the Postman collection automated by that Jenkins job. Next to it are displayed the hash of the last git commit, as well as the Talend version, which corresponds to the API version being tested. The API version is extracted from Elasticsearch. These version numbers help track after which update bugs appear or disappear.
What’s especially interesting here are the failures and their causes:
- The test title explains which value is being tested. The assertion below compares the expected value to the actual value.
- To better understand the input data that caused the issue, the headers and body of both the request and response can also be viewed.