On Fri, 25 Feb 2022, 18:46 'Markus Zimmermann' via golang-nuts, < golang-nuts@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+unsubscr...@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/CAJhgach5KZm%2Bf3t0mktKTiY2mik6MRSPb2QAfPcYOePOnOU2yg%40mail.gmail.com.
