On Thu, 2022-03-03 at 05:50 -0800, twp...@gmail.com wrote:
> 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
>
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 failin
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/c
On Fri, 2022-02-25 at 09:26 -0800, 'Markus Zimmermann' via golang-nuts
wrote:
> 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.
I'm struggling to understand how you captu
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
