To identify failing test cases in a table of tests where you don't have
individual names you can use its index:
for i, testCase := range testCases {
t.Run(strconv.Itoa(i), func(t *testing.T) {
// ...
For debugging an individual test case, just skip over all but the failing
test case:
for i, testCase := range testCases {
if i != 5 { // 5 is the index of the failing test, remove if
statement before committing
continue
}
t.Run(strconv.Itoa(i), func(t *testing.T) {
// ...
It's a quick cheap hack, but occasionally useful.
On Monday, February 28, 2022 at 9:48:52 PM UTC+1 rog wrote:
>
>
> On Fri, 25 Feb 2022, 18:46 'Markus Zimmermann' via golang-nuts, <
> golan...@googlegroups.com> wrote:
>
>> Hi Gophers!
>>
>> We were unhappy with the common unit test styles and we think we found a
>> style that has clear advantages. An in-depth comparison can be found here
>> https://symflower.com/en/company/blog/2022/better-table-driven-testing.
>>
>> We also added support for maintaining such tests in our VS Code extension
>> https://marketplace.visualstudio.com/items?itemName=symflower.symflower.
>> You can either use the command or the context menu item to maintain tests.
>> Here is a short introduction video
>> https://www.youtube.com/watch?v=mgWLY9DDyDE&ab_channel=Symflower
>>
>> There are some changes necessary to have better stack traces for
>> github.com/stretchr/testify because "t.Run" calls the test function from
>> another location. We are in the process of upstreaming them. Until then you
>> can find them in our fork at https://github.com/symflower/testify.
>>
>> Would appreciate your feedback on the style and extension. Would be also
>> interesting to hear other approaches and conventions that could help others
>> to write better tests.
>>
>> Cheers,
>> Markus
>>
>
> One disadvantage of your approach: the table can't be reused for different
> tests. Not uncommonly I've found that it's useful to be able to plug the
> same table into more than one testing function - after all, the test data
> is an abstract description of some property and there can be more than one
> way of testing that property.
>
> I usually do something half way between the "standard" approach and your
> suggestion. I have a struct with a "testName" field ("name" is too easily
> confused with input data IMHO), and I'll use T.Run to run it as a subtest.
>
> I've found that the lack of stack trace is much less of a problem if you
> use a test name that isn't mangled by the testing package - in other words:
> don't use spaces! That way a simple text search in your editor will usually
> take you straight to the relevant table entry.
>
> cheers,
> rog.
>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/4c52a6b6-6762-442c-b9b8-82b8f50a732dn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/4c52a6b6-6762-442c-b9b8-82b8f50a732dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/b2476893-2744-48e3-a990-a8f721c77ef3n%40googlegroups.com.
