Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: allow command line arguments instead of an xml #39

Open
RoelvandenBerg opened this issue Jul 13, 2022 · 2 comments
Open

Comments

@RoelvandenBerg
Copy link

RoelvandenBerg commented Jul 13, 2022

Request

  • I would like to be able to a run a test on a docker team engine container by just giving an url without having to mount an xml.
  • I would like the script to optionally return an exit 1 when the tests fail.

Usecase
Both requests would make running tests in continuous integration easier (e.g. could create an integration test that shows a service remains ogc compliant), just as it would for regular regression tests that check the validity of services as they are running. We would be able to parametrize the output.

Possible implementation
An example implementation without editing the team engine code: https://github.com/PDOK/ets-ogcapi-features10-docker

@dstenger
Copy link
Contributor

Thank you for providing this feature request.

In general, this repository currently does not provide CLI functionality via Docker but a Tomcat is started containing the webapp of TEAM Engine and a selection of test suites.

So, your proposal is to also provide separate Docker Images which can be used as CLIs.

First question would be if there shall be one Docker Image containing multiple test suites or one Docker Image for each test suite.

Also, we have to consider that there are two different mechanisms of using test suites as CLI.

  • TEAM Engine CLI
  • *-aio.jar
    • Is just supported by TestNG test suites (does not work with CTL test suites)
    • Each test suite has its own *-aio.jar
    • Your referenced approach seems to use the *-aio.jar

Second question would be to decide which of the two options shall be used.

@RoelvandenBerg
Copy link
Author

I don't think seperate *-aio.jar images are necessary. We just used the one because we needed that one for our test and found a readme with that particular setup. A larger image that contains all tests would probably even be better if (as I presume) that would make them much bulkier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To do
Development

No branches or pull requests

3 participants