Add recommendation on using table tests for single case tests.

[rabbbit]

The exact wording is TBD - this is to start a discussion.

My personal preference is to use table-test all the time, and would obviously would like it to be recommended.

However, the primary goal is to avoid arguing in the code reviews. I am okay with the other version too (no table tests for single case tests), as long as we call something out here.

[abhinav]

I would advise the opposite: don't table test until you need it.
Table testing too early can also lead to overly complicated table tests with twisting, branching test code like "if flag, do this extra bit", "if flag, set up the mocks like this," etc.
We should aim to keep the complexity of the actual test code simple, and adding a table too early might take us in the wrong direction.

[rabbbit]

@mway - you had other comments, I believe?

@abhinav what annoys me mostly is when we have a table test, we remove one of the 2 cases, then we have a well-formatted test, but then converting test to non-table test means 20+ line change.

I see how the premature branching might a problem ... but also it's nice to read code like (paraphrasing):

tt := struct{
   name: bla,
   have: some input
   want: some output
}
// some 100 line test code here

makes it easier to see what actually matters in the tests, rather parsing input/output here in the body of the test.

[abhinav]

@rabbbit I'm completely on-board with table tests when there are multiple test cases. I agree give and want, especially for simple input-output relationships make it really easy to follow the tests.

I'm advising against premature tables because the existence of the table test for a single test case will push the next test case to be an entry in the table, even if it would be better expressed as an independent test or subtest. Adding a table test too early is akin to creating an abstraction to reduce duplication before we know what the duplication looks like.

Part of the reason for this line of thinking is social: the next person who changes that code may not be confident in what and how much they're allowed to change, so they may want to keep their footprint small. (Anecdotes suggest that this is not uncommon.) They'll pattern match on existing tests, assume there's a good reason for the table, that all tests for Foo must be in the TestFoo table, and shoehorn their new test case in there even if it doesn't fit properly.

when we have a table test, we remove one of the 2 cases, then we have a well-formatted test, but then converting test to non-table test means 20+ line change.

I feel like that has to be very rare--to have a table with only two test cases, one of which you are deleting. (Normally the test case count goes in the other direction.) But, if you're really running into this, I'm sure an exception can be made: When modifying existing test cases, if the test is already using table tests, don't change its nature.

That said, for simple enough tables, you can sidestep the issue: just add a second test case. It can't be that hard to add a second test case for something that merits a table test.

Separately, on the benefit of input and output declared at the top followed by 100 lines of code. You can still do that without a table test:

have := // some input
want := // some output

// some 100 lines of code here

In fact, that prepares that test nicely to become a table test in the future, should the need arise.

[abhinav]

I think this is superseded by the recent changes to the table test section.
@rabbbit is this good to close?