When trying to debug_test a suite case it wrongfully assumes there are no tests #98

Closed
opened 2024-09-16 22:55:57 +03:00 by brunobmello25 · 6 comments
brunobmello25 commented 2024-09-16 22:55:57 +03:00 (Migrated from github.com)

Steps to reproduce:

  1. initialize a new go module with go mod init ...
  2. create an src folder with a main_test.go file
  3. add this content to the main_test.go file:
package main

import (
	"github.com/stretchr/testify/suite"
)

type SomeTestSuite struct {
	suite.Suite
}

func TestSuite(t *testing.T) {
	suite.Run(t, new(SomeTestSuite))
}

func (st *SomeTestSuite) TestSomething() {
	st.Run("some test here", func() {
		st.Equal(2, 1)
	})

	st.Run("another test here", func() {
		st.Equal(3, 2)
	})
}
  1. try running require('dap-go').debug_test() with the cursor inside one of the two st.Run(...) suites. For example, assuming you run on the second st.Run, note that there will be a vim message like starting debug session './src : another_test_here', which is the correct name, but then in the repl window you will see that it didn't find any test.
Steps to reproduce: 1. initialize a new go module with `go mod init ...` 2. create an src folder with a `main_test.go` file 3. add this content to the main_test.go file: ```go package main import ( "github.com/stretchr/testify/suite" ) type SomeTestSuite struct { suite.Suite } func TestSuite(t *testing.T) { suite.Run(t, new(SomeTestSuite)) } func (st *SomeTestSuite) TestSomething() { st.Run("some test here", func() { st.Equal(2, 1) }) st.Run("another test here", func() { st.Equal(3, 2) }) } ``` 4. try running `require('dap-go').debug_test()` with the cursor inside one of the two `st.Run(...)` suites. For example, assuming you run on the second `st.Run`, note that there will be a vim message like `starting debug session './src : another_test_here'`, which is the correct name, but then in the repl window you will see that it didn't find any test.
leoluz commented 2024-10-03 05:49:02 +03:00 (Migrated from github.com)

Not sure but it seems that something is wrong with your test. I created the same folder structure than you and validated that the following test works fine:

package main

import (
	"fmt"
	"testing"
)

func TestSuite(t *testing.T) {
	t.Run("subtest with function literal", func(t *testing.T) {
		t.FailNow()
	})
}

func TestSomething(t *testing.T) {
	t.Run("some test here", func(t *testing.T) {
		t.SkipNow()
	})

	t.Run("another test here", func(t *testing.T) {
		fmt.Println("here")
	})
}

I added breakpoints in all 3 tests the was able to debug as expected.

Not sure but it seems that something is wrong with your test. I created the same folder structure than you and validated that the following test works fine: ```golang package main import ( "fmt" "testing" ) func TestSuite(t *testing.T) { t.Run("subtest with function literal", func(t *testing.T) { t.FailNow() }) } func TestSomething(t *testing.T) { t.Run("some test here", func(t *testing.T) { t.SkipNow() }) t.Run("another test here", func(t *testing.T) { fmt.Println("here") }) } ``` I added breakpoints in all 3 tests the was able to debug as expected.
brunobmello25 commented 2024-10-03 16:01:08 +03:00 (Migrated from github.com)

Not sure but it seems that something is wrong with your test. I created the same folder structure than you and validated that the following test works fine:

but where are you placing your cursor when running debug_test? if my cursor is placed inside a specific t.Run it log a warning that there are no tests to run. see this first screenshot:
image

however, if you place your cursor inside the TestSuite function, then it will run, but it will run all t.Run suite methods inside the TestSomething function, where we actually only want to run one (first case)
image

> Not sure but it seems that something is wrong with your test. I created the same folder structure than you and validated that the following test works fine: but where are you placing your cursor when running debug_test? if my cursor is placed inside a specific `t.Run` it log a warning that there are no tests to run. see this first screenshot: <img width="1067" alt="image" src="https://github.com/user-attachments/assets/535f0113-ce32-4d7c-b1a7-a4cc26375fbd"> however, if you place your cursor inside the `TestSuite` function, then it will run, but it will run all `t.Run` suite methods inside the `TestSomething` function, where we actually only want to run one (first case) <img width="1067" alt="image" src="https://github.com/user-attachments/assets/cd427301-ff03-411c-aedc-f69ea4680f03">
leoluz commented 2024-10-04 14:23:27 +03:00 (Migrated from github.com)

It is probably caused by the signature of your
TestSomething() function. Try to declare it as TestSomething(t *testing.T) instead.

It is probably caused by the signature of your `TestSomething()` function. Try to declare it as `TestSomething(t *testing.T)` instead.
brunobmello25 commented 2024-10-04 16:16:38 +03:00 (Migrated from github.com)

still the same problem, it doesn't find any tests to run .

It would work if I used the t object instead of the suite, but then I'd not be respecting the suite way of writing tests

image
still the same problem, it doesn't find any tests to run . It would work if I used the `t` object instead of the suite, but then I'd not be respecting the suite way of writing tests <img width="1157" alt="image" src="https://github.com/user-attachments/assets/9075ffa9-28c1-4c16-9cf3-93d39709f311">
leoluz commented 2024-10-05 07:14:56 +03:00 (Migrated from github.com)

It could be something related with the treesitter queries used to identify tests and sub-tests. It needs investigation in that part of the code: leoluz/nvim-dap-go@6aa88167ea/lua/dap-go-ts.lua (L3-L25)

It could be something related with the treesitter queries used to identify tests and sub-tests. It needs investigation in that part of the code: https://github.com/leoluz/nvim-dap-go/blob/6aa88167ea1224bcef578e8c7160fe8afbb44848/lua/dap-go-ts.lua#L3-L25
stale[bot] commented 2025-04-04 04:03:55 +03:00 (Migrated from github.com)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
NeonXP/nvim-dap-go#98
No description provided.