nicolaferraro commented on issue #600: Testing Camel K integrations URL: https://github.com/apache/camel-k/issues/600#issuecomment-509171773 After some brainstorming here and there I'd proceed with a POC about that. We want to remain without project structure for camel k integrations, to keep everything simple and portable. For this reason, testing frameworks requiring a structure and complex dependencies are not well suited. A possible format for test files is the [Gherkin](https://github.com/cucumber/cucumber/tree/master/gherkin) language from Cucumber. It requires a simple `.feature` file that can contain BDD statements. We want to focus on integration testing, so a framework like Citrus is well suited for this and Citrus already supports many kind of Gherking statements. We'll add some of ours. E.g. taken from Citrus doc: ``` Feature: Voting Http REST API Background: Given URL: http://localhost:8080/rest/services Given variables | id | citrus:randomUUID() | | title | Do you like Mondays? | | options | [ { "name": "yes", "votes": 0 }, { "name": "no", "votes": 0 } ] | | report | true | Scenario: Clear voting list When send DELETE /voting Then receive status 200 OK Scenario: Get empty voting list Given Accept: application/json When send GET /voting Then Response: [] And receive status 200 OK Scenario: Create voting Given Request: """ { "id": "${id}", "title": "${title}", "options": ${options}, "report": ${report} } """ And Content-Type: application/json When send POST /voting Then receive status 200 OK Scenario: Get voting list When send GET /voting Then validate $.size() is 1 Then validate $..title is ${title} Then validate $..report is ${report} And receive status 200 OK ``` Tests can be very simple or also complex with this approach. Although it won't reach the complexity allowed in a Java test class. We can create a "IntegrationTest" custom resource to drive the test. Tests will be still using Citrus under the hood and they'll be driven by the operator. This way the test is independent on any CLI but we can still obtain the state of the tests from CLI. Having them as resources also help integrating tests with a CI. `Gherkin` will be the first "format" we support, but we can add others later.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
