Add some acceptance tests and integrate automated tests into Jenkinsfile about aloha

[metmajer]

Thanks @rafabene, I will want to have a look into it soon!

[rafabene]

Thanks @metmajer . Definitely tests are one of the most important item in a CI/CD Pipeline. As you saw, the current Jenkinsfile has a "placemark" for it, but we never had time to implement at least the unit tests.

The integration tests is something that is not planned for this demo given that we couldn't deploy all other microservices in the dev and staging environments, otherwise it would be too heavy to be executed in a laptop.

But I really would be very thankful if you want to contribute with an acceptance test for this project.

[metmajer]

Hi @rafabene, I was just able to dedicate time to this, so let's please share thoughts: for this application, I'd suggest to have acceptance tests verify the correct response of the respective REST endpoints, such as /api/aloha and /api/health. Later, the test cases could be extended to assert proper service rendering and response on the frontend microservice.

Acceptance tests verify whether a contract between the development team and the customer holds true and so they are typically not part of the application under test. So I've been thinking about the right framework for executing these tests and then came across CasperJS. CasperJS is a tool for navigation scripting and testing, which includes a headless browser, and supports a rather simple, declarative DSL. Here's an example on testing the search results of a Google search.

Recently, I worked on a little side project to Dockerize CasperJS and make it accessible via a simple REST API. The Docker image could be used as a service on OpenShift and then issue tests against the various microservices, but this is really just one possibility.

What are your preferences? Thoughts?

[rafabene]

Awesome! This seems very interesting. I'll involve also @lordofthejars as we started to discuss alternatives for microservices testing. We could work together to align what is the Red Hat's message about microservices testing.

Thanks for sharing your thoughts.

[lordofthejars]

Hi, that's great, I see here several different tests. In one place I see Unit tests which can be written using plain JUnit. Then also there are component tests that can be written using vertx test framework.

Then using academic terms we are talking about acceptance tests and contract tests (or Consumer-Driven contracts). The big big difference between them is that acceptance tests are tests that validates functionality from the point of view of business/ROI, meanwhile contract tests just validates that the contract that both consumer and provider has agreed to follow, are followed by both parties. For example service A talks with Service B you want to validate that Service B follows the contract and produces valid messages that consumer is going to be able to parse. On the other side Service A just validates that he will be able to make requests to provider and get the responses.

Probably for Acceptance tests where a browser might be implied CasperJS is a really good choice. In case of contract testing in Red Hat we are working in Arquillian Algeron that basically it is a test framework based on Arquillian for running Contract tests. Currently we only support Pact format but we have a plan to support swagger as well.

Notice that the good thing about Pact is that it works with Java, .Net, Go, Javascript, ... so it is reallly a mature technology.

During this week and next week I had in my agenda writing an example on how to use Vertx with Arquillian Algeron so then it can be used in any other project.

[metmajer]

@lordofthejars, I'd be highly interested in your example. Got something to share yet?

[lordofthejars]

Not using VertX but using other Java technologies

[armdev]

Thanks for sharing this project, this is example of professional development!