You would need your own reporter.
If you want to spend time creating one, we could add it to the framework.
A guide for creating reporters cold probably be helpful too.

okay.. so I've started created a table_reporter.. i started with copying one of the existing ones (i think xunit _reporter)
it works by outputting all the data at the end in teh after_calling_run method

this was working fine until i tried to save the expectation results and found there is only
ut_test.failed_expectations and not an equivalent passed/skipped expectations.

is this correct or am i missing something? can i get a list of passed/skipped in teh after_run event or do i need to rewrite and log stuff incrementally ?

Storing results in table is not providing much value as one needs to build something on top of it to be able to use it.
We deliberately made decision to make the framework stateless, so developers can say "i don't care if it's the same database, as long as it is acting the same way"
Imagine you're running your development in the cloud where you get one of 1000 databases as your development database.
You wouldn't probably go looking for your test results in one of those 1000 db's.
You'd need something that is outside of those 1000 db's to collect test results and give full overview of all executions.
This is where CI/CD tools come in play.

my particular use case it to integrate with other tooling that already uses tables created as part of a home grown unit test framework.

i hope its more of an interim step before updating those tools also.

OK, got it.
For the failed_expectations - this is my doing in #500. I've removed the successful expectations some time ago to minimize the memory hit for large suites - storing each expectation result can be costly.

It seems like we we actually could use the full set of expectation results as well as list of failed expectations only.

This will mean a bit of refactoring and moving responsibilities between objects.

@Shoelace .
I'm adding all_expectations as an attribute for ut_test class.
The existing failed_expectations will still be in place.

You can see changes in #545.
That should get you sorted.

With #589 we will be able to have custom reporters. I think we can close this and #541 once the PR is merged, right?

Possible with custom reporters.
Closed by #589