Continuing the discussion from Better way to debug single unit test in tidb:
There will be so many works to do, but we can discuss whether it is a good direction.
Continuing the discussion from Better way to debug single unit test in tidb:
There will be so many works to do, but we can discuss whether it is a good direction.
Yep. From my previous prototype, which we need to do is,
For a pre-RFC, we might also need to collect clear pros and cons on this proposal.
An advantage is that testify exposes testing.T
from its suite by T()
while I don’t see a clear way how to achieve it in go-check.
Accessing testing.T
is useful when we try to redirect logging output to testsuite and flush only if test failed.
See also
testify seems suffer from some parallel testing issues:
… continue diagnostic
@TennyZhuang I’ve made a draft of pre-RFC
More details will be present later and I’ll appreciate if anyone comment there.