search

ttutisani / Xunit.Gherkin.Quick

BDD in .NET Core - using Xunit and Gherkin (compatible with both .NET Core and .NET)
MIT License
205 stars 29 forks source link

Double-clicking a scenario in the test runner should take you to the scenario file #4

Open csurfleet opened 6 years ago

csurfleet commented 6 years ago

It would be great if the scenarios in the test runner behaved like normal tests - double clicking to take you to the test in code. Ideally this would open the scenario file, or if not the steps file would be reasonable

I'm not sure if this is even possible, but I'll take a look in the next few days.

ChristianPejrup commented 6 years ago

I did a few hour investigation of this issue - my findings are.

The issue

xUnit only supports tests being "methods" (not a class) the xUnit implementation that calls IXunitTestCaseDiscoverer only parses in method's that have been decorated with FactAttribute (or a derived type).

Current implementation "fakes" the relationship between method and the feature class by having a internal method Scenario in Feature.cs this where the test runner will open when double clicking.

Speclfow

The way Specflow handles this is by generating some code behind that can be referenced (i dont know how/why it is able to jump to the Gherkin feature file).

Alternatives

  1. Code generation I'm not sure this is a good solution as the testrunner will only take you to the auto generated code which will probably be useless.

  2. xUnit might have another way to discover tests that is possible to hook into I think a good place to start is in ExtensibilityPointFactory.cs (Xunit.Sdk) which defines the different points of extensibility

  3. Hack

    • Add one function that implements Fact (this is only to trigger IXunitTestCaseDiscoverer.
    • In IXunitTestCaseDiscoverer (ScenarioDiscoverer.Discover) perform the logic of searching for Feature files in the solution (today it only searches on the object of the test method that was parsed in).
    • Generate ScenarioXUnitTestCase for each Scenario. The problem with this approach is to fake the testMethod (seems like this is the information that is used to find the location to change to when clicking on the test in test explorer) It does not look like it is possible to reference something that's not actually a method so referencing .Feature is probably not possible The logic for constructing the Location of the test is located in xunit.runner.visualstudio/VsTestRunner.cs