Thanks for reporting. Can you please check if suite.Run works for you?

func (suite *Suite) TestFoo() {
    suite.Run("foo", func() {
        // do smth
    })
    suite.Run("bar", func() {
        // do smth other
    })
}

I haven't got the time right now, but if you wish you can try adding a test among the existing testify tests and then modify the queries in https://github.com/fredrikaverpil/neotest-golang/blob/main/lua/neotest-golang/features/testify/lookup.lua that mentions suite.

For example, you should be able to do something like this (two occurrences in the file):

- operand: (identifier) @suite_lib (#eq? @suite_lib "suite")
+ operand: (identifier) @suite_lib (#match? @suite_lib "^[suite|s]$")

Hello, thanks for answering.
Case with suite doesn't help unfortunately.
I changed all lines with operand @suite_lib to add s receiver as you provided, but without success either.

As I can understand these queries, testify/lookup.lua contains queries for parsing like "starter" function for testify, which let standart golang test mechanism start testify suite.

My problem is with detecting subtests (e.g. table tests) which are defined in query.lua at the root (almost).
There were some changes, which now allows using only t as a receiver in subtests

Ah yes, I think I made a mistake earlier then. I need to dig into this and see what to do. I think I would like to limit the use of s.Run and potential other variants to when you have the option testify_enabled = true only.

@uroborosq would you mind giving the testify-operand branch a try?

{
  "fredrikaverpil/neotest-golang",
  branch = "testify-operand",
}

I think this might work. I just need to add some tests into #280 to verify it.

@fredrikaverpil ok, thanks I will try in the nearest future

Yes, it works but only for usual tests like

s.Run("foo", func() {
 // smth
})

but unfortunately doesn't work for table tests with such structure

cases := []testCase{ {name: "foo" ... }}
for _, test := range cases {
    s.Run(test.name, func() {
    ...
    }
}
}

Table tests are not something I ever added support for, when it comes to testify. They are only supported for "vanilla" tests. Are you saying table tests used to work with testify? 🤔

The current testify specific tree-sitter queries would have to be extended to support table tests. I'm open to PRs which would enable this, but I don't plan on implementing this myself, as I don't use testify.

Table tests had been working good enough until bd8e69e

There is no any significant differences between vanilla testing and testify table tests in my opinion, just using suite receiver instead of testing t, so yes, it worked

Okay, interesting. I can probably re-introduce this behavior fairly simply in that case.

It's somewhat funny that all of that was a side effect of having the base treesitter queries mixed with the testify treesitter queries. It's probably a good idea to not mix them and instead have two different set of queries so to avoid future bugs.

I'll look into it.