Currently report_results runs the tests and prints pass/fail information to the console as side-effects, but it does not return pass/fail information to the caller. Specifically, it either returns (after performing its side effect) if everything passed, or error stops if any failure was detected.
This design captures a common use case, but prevents the client's test driver program from making its own decision about what consequences should occur based on the passing or failing of the test suite.
A potentially better solution would be to add optional intent(out) arguments from report_results to return the number of passed/failed/skipped tests to the client's test driver (without error stop, when provided), allowing the client to make its own decision about whether and how to error stop.
Currently report_results runs the tests and prints pass/fail information to the console as side-effects, but it does not return pass/fail information to the caller. Specifically, it either returns (after performing its side effect) if everything passed, or error stops if any failure was detected.
This design captures a common use case, but prevents the client's test driver program from making its own decision about what consequences should occur based on the passing or failing of the test suite.
A potentially better solution would be to add optional
intent(out)arguments fromreport_resultsto return the number of passed/failed/skipped tests to the client's test driver (without error stop, when provided), allowing the client to make its own decision about whether and how to error stop.