Support for [Test] and [TestCase] attributes on same test

[Coding-Journey]

Hi, neotest-dotnet adapter is great, enjoying using it to run .net tests, only 1 issue I'm facing:

"Using the [Test] attribute alongside [TestCase] attributes on the same method will cause neotest-dotnet to duplicate the item with erroneous nesting in the test structure. This will also break the ability of neotest to run the test cases"
https://github.com/Issafalcon/neotest-dotnet?tab=readme-ov-file#nunit-limitations

Surely there is some kind of parser that can be added here? If there is a [Test] attribute on the line above a [TestCase] attribute, ignore the [Test] attribute?

Unfortunately our company codebase has lots of [Test] and [TestCase] attributes on tests together. We generally justify them with single responsibility principle, one attribute to define the fact it's a test, one attribute to give it a test case.

I'm surprised that this is an issue with NUnit, all the tests run correctly within VS; I wonder what they do differently?

Changing all the tests to not have this [Test] attribute is not a viable solution, any ideas on how I can run test cases without removing the [Test] attribute please? (Happy with either existing config fixes or direction to create a fork/pr - given there aren't reasons that this hasn't been done already that I'm missing)

[Issafalcon]

Hi @Coding-Journey - Thanks for raising the issue, and glad you are finding the plugin useful.

I think you are right, in that this is possible to do. For NUnit, I have an issue on my todo list (#90 ) which will help solve this issue in a more robust way. If you look into that same issue, someone has highlighted the vstest protocol, which is essentially how this adapter differs from VS and VSCode. At some point, this will probably be the way to go to make this adapter more like the Microsoft owned ones, but it will take some time and effort. However, I am very limited on time at the moment, with a new baby arrival, and other things going on that are eating my time.

A workaround could be possible by modifying the treesitter code, which I can take a look at when I can squeeze some time in.