Proposal: Restructure TiDB Tests

#23

thanks, can’t agree more

#24

Hi, audience of this thread.

I’d like to share you an under reviewing dev guide section Write and Run Unit Tests. It collects best practices found in this effort and hopefully we guide every developer how to write unit tests in idiom and run tests by yourself.

Your feedback is highly appreciated.

2 Likes
#25

This proposal looks great, but may I ask an additional question in the intermediate state.

I see some of the tests in TiDB are already migrated to testify, which brings me some troubles.

During development, we used to run some unit tests(let’s classify MustExec as a unit test by now) to test if my code works. In which, I use go test -timeout 3s ./executor -check.f ^TestNameOfFunc$ to run the specific unit test. However, without failpoint enabled, the test failed by some tests under testify framework which is dependent on failpoint. Of course, I do not want to involve these test cases, as a workaround, I have to temporarily add a return at the beginning of the failed test like

func TestSomething(t *testing.T) {
	return
	// test codes which is dependent on failpoint 
}

This solution seems a little tedious, do you guys have any simpler ways to run the specific test under the check framework?

#26

You can run by -test.run ^TestT$ or something like it.

The rationale is that we just use testify matchers so it is actually run under go testing framework, where go-check registers TestT as its entrypoint.

So, you can combine these mechanism, by first filter out TestT only, and then use -check.f to select the function. For the long-turn, we will migrate all test, and you just replace -check.f with -test.run, which is out-of-the-box by go testing.