You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently using the TestMain function to setup and teardown test-containers in our integration tests. This allows us to prepare the environment once for the entire test suite and save time.
We also monitor our test CI step by using gotestsum which practically parses the output from go test -json. This lets us keep the CI snappy.
One issue we are having is that there is no way to monitor TestMain's timing or outcome. In gotestsum there is some code to add a fake test case in the case the failure occurred in TestMain (see comment by @dnephin ). But, there is still no way to monitor how long did the logic before and after the tests ran.
There are several possible ways to tackle this IMO:
note testing.M.Cleanup was previously declined in #42161
Thanks for the reference. I think there is another valid use case here which I didn't see in that proposal. Also, we can achieve TestMain timing without these as I suggested.
Hi,
We are currently using the
TestMain
function to setup and teardown test-containers in our integration tests. This allows us to prepare the environment once for the entire test suite and save time.We also monitor our test CI step by using gotestsum which practically parses the output from
go test -json
. This lets us keep the CI snappy.One issue we are having is that there is no way to monitor
TestMain
's timing or outcome. In gotestsum there is some code to add a fake test case in the case the failure occurred inTestMain
(see comment by @dnephin ). But, there is still no way to monitor how long did the logic before and after the tests ran.There are several possible ways to tackle this IMO:
Declaring setup and teardown functions
Introduce new functions for setup and teardown:
This can work just like
testing.T.Cleanup
does. I think this is beneficial for other use cases where there is a need to better organize testing code.Emitted JSONs could look like:
Monitor
TestMain
timing withoutm.Run
timeAnother option is to time the entire
TestMain
but stop the timer onm.Run
and resume when it ends.Hypothetical code:
Emitted JSONs could look like:
The text was updated successfully, but these errors were encountered: