After running microcks test, the CLI exits with a pass/fail result and a link to the web UI. If you want to look at the history of test runs for a service (how many ran, when, which endpoint was tested), you still have to open the browser.
Microcks already exposes this via GET /api/tests?serviceId=<name:version>, so the data is there. It just needs a CLI surface.
A simple command like:
microcks tests list "WeatherForecast API:1.1.0"
could print a table showing the test ID, date, runner type, tested endpoint, and pass/fail status for each run.
This makes it easier to debug flaky test runs, audit what was tested and when, and confirm that a recent import actually triggered a new test, all without leaving the terminal.
It also ties into the VS Code extension work in #255, where showing recent test results per service is one of the expected views.
@lbroudoux @yada @Harsh4902 does this fit the CLI roadmap? Happy to open a PR once there is a thumbs up on the direction.
After running
microcks test, the CLI exits with a pass/fail result and a link to the web UI. If you want to look at the history of test runs for a service (how many ran, when, which endpoint was tested), you still have to open the browser.Microcks already exposes this via
GET /api/tests?serviceId=<name:version>, so the data is there. It just needs a CLI surface.A simple command like:
microcks tests list "WeatherForecast API:1.1.0"could print a table showing the test ID, date, runner type, tested endpoint, and pass/fail status for each run.
This makes it easier to debug flaky test runs, audit what was tested and when, and confirm that a recent import actually triggered a new test, all without leaving the terminal.
It also ties into the VS Code extension work in #255, where showing recent test results per service is one of the expected views.
@lbroudoux @yada @Harsh4902 does this fit the CLI roadmap? Happy to open a PR once there is a thumbs up on the direction.