stretchr / testify

A toolkit with common assertions and mocks that plays nicely with the standard library
MIT License
23.15k stars 1.59k forks source link

Assert: go test output shows subtests that fail as PASS #1521

Closed Anacardo89 closed 9 months ago

Anacardo89 commented 9 months ago

When running a test with various subtests with t.Run(), set to fail, the test itself fails, but the substests all show as passed in the end, so there's no quick way of checking which subtest failed, apart from checking the line in the editor.

This doesn't happen if using the std library instead of assert

image

image

Without t.Parallel() it gets easier to tell which subtest failed, since they fail as they're called, but that's a strenuous limitation.

image

Anacardo89 commented 9 months ago

So i fiddled around with if for a bit and find that it doesn't reproduce if i don't create a new assert and just pass t everytime i call it:

image

image

So there's a workaround at least.

I looked around the t.Run and assert implementations and got confused but i think it's related to assert.t not being the same as t that is used in t.Run

image

so when Fail() calls t.Errorf(), which calls it's own Fail() it's modifying different t's?

image

image

image

But if that was the case then it wouldn't only not set c.failed, i would also not set c.parent with Fail()

As i said, i'm confused, this is confusing, imma go study interfaces now and hope that sheds some light into the matter, at least to me.

tscales commented 9 months ago

You're basically on the right track. The top level testing.T that you pass in to assert.New and the testing.T created when invoking t.Run are different. In your first example, no assertions are made against your subtest so its reports passing. You would basically have to do something like this.

func TestNotNil(t *testing.T) {
    a := assert.New(t)
    t.Run("Test Not Nil Sub", func(t *testing.T) {
        passed := a.NotNil(t)
                if !passed {
                    t.Fail()
                }
    })
}

but as you discovered, you can skip using assert.New all together.

Anacardo89 commented 9 months ago

I get it, since i'm declaring a outside t.Run(), even if i use it inside, it will reply to the whole test so i have to manually fail t.Run(). a isn't failing the parent, it still IS the parent and fails itself. Thank you, this insight was really helpful