ttutisani/Xunit.Gherkin.Quick

Feature file and test not discovered by test runner

cathalmchale opened this issue · 7 comments

The Features text files are very particular about text encoding.
I had an issue where a new Feature file and corresponding test class would not be discovered and would not run (locally or on build box). But many existing features existed and run without issue.
I created new files with new names and cleaned up the text and simplified the Feature and test to absolute basics. Nothing worked, the test would not be discovered.

So I took a Feature file that I knew worked and copied it as a starting point. Then manually edited it so that it eventually looked like the one the didn't work. But this time the test could be discovered and run, without issue.

Looking at the two files (Working.feature and NotWorking.feature) in Notepadd++ with special chars highlighted or in BeyondCompare revealed nothing useful. However, I don't doubt that there was something abnormal about the encoding.

Summary
If you have a Feature file that refuses to be discovered by the test runner, but have other files that are being discovered fine, copy one of the good ones as a starting place and avoid copy-paste from PDFs etc.

Thank you @cathalmchale , this is a useful finding!

No problem @ttutisani thanks for the framework, I'm enjoying using BDD for the first time!
I have some general notes I've taken for myself. I'll include them here. If you want, I can edit and remove them again. But they may be useful / could be incorporated in the help files (I might add as a contribution if I get around to it).

Main issues

  1. It's mostly plain text in the Feature files, but there are some special characters
    to be aware of:
    + < ( ) \
    This is because you then copy this text to the unit test attribute,
    and here it is used to form a regex. So any character that can cause trouble there
    should be avoided.

  2. Feature files are very sensitive to character encoding.
    In short: Any problems having your test discovered, just copy a known good file
    and use it as a starting place. Edit manually and avoid copy-pasting from PDFs etc.
    Sounds simple, but this cost a lot of time:
    #82

  3. Minus numbers captured as (-\d) in the test attribute. This isn't great, because
    ideally the Feature file could feed any number to the test. But with this syntax,
    you're forced to specify negative numbers up-front and can't change this with the
    same binding.

  4. In general (to learn more about xunit.gherkin.quick / Gherkin syntax):
    Trick seems to be to study the code base - the documentation is incomplete.
    E.g. see test files and matching feature files

@cathalmchale all great points!

I guess each of these would be either added to the existing docs or created as a separate doc, case-by-case.
If you find the time, feel free to contribute with doc file updates. If not, it would be helpful if you could mention for each of the items, where you would expect that note to be found. Your (reader's and consumer's) perspective helps because I want to add this documentation where it makes the most sense and would be valuable to people like yourself.

Regardless, all your findings will be incorporated into documentation at some point, because they can help somebody in the future.

@ttutisani will try make a contribution in the markdown help. shouldn't take long.

One more for luck that might catch a few:

  • Resharper test runner appears to work. But when you add Backgrounds and Scenario's it looks like it's only running one of the connotations. I thought I had something wrong in the Gherkin syntax and started adjusting that. But I discovered that there was no issue and the multiple connotations were visible in the Visual Studio test explorer, or in the test results on the build box.

Yes, absolutely, I already saw that issue but it's not mentioned in the docs. ReSharper test runner is not friendly with Xunit.Gherkin.Quick because it does not honor everything that Xunit has and this framework uses to run.

@cathalmchale I think this issue can be closed as all reported items were addressed in your recent PR. Is there anything left in here that is not yet addressed?

All good. Thanks.