Feature discoverable by pattern.

[miguelius]

This is WIP. Not to merge yet. I couldn't run the tests because I am working on Linux and they don't run with dotnet core 6 runtime.

It pretends to solve issue #64.

There are some issues regarding to the way that Feature Class is coupled to Feature File. To bypass this, we send it as an argument when we discover the features, but i would be nicer to have a better solution.

If you build the dll and add it to an existing project, in the FeatureClass you can add something like this:

[FeatureFileSearchPattern("./Features/ConsultaHuerfanos*.feature")]
public sealed class ConsultaHuerfanosFeature : Feature

And it should work find the files and bind it to the Feature.

By default it searches for ClassName*.feature.

Improvements, reviews and ideas with the fork are welcome.

Cheers!

[ttutisani]

What will happen if two files match the pattern?

[miguelius]

It's exactly the scenario we are looking for. We'd like to have many feature files sharing the steps of a Feature Class.

It keeps them tracked with the extra-argument in the execution.

I am adjusting the tests to the discovery model.

[miguelius]

Tests fixed.

Main changes: Discover now returns Featue instance and file. Since executions parses them from the filles we had to passed its path.

We return a tuple, but it would be nice to have some derived class from feature including the path to trace it or some other structure.

In the current state you can:

• define a class in the classic way
• define using the searchpath attribute
• use both

The model will discover all the files matching and return in a similar way of the missing features.

We are giving this a test drive with a local project and refactors are welcome. We will provide the tests for the described behaviour.

I understand it can be improved but we wanted to give back to your community and you our humble work. This is a way of saying thank you.

It's a great project and very well documented and maintained! Congrats

Cheers!

[ttutisani]

Thanks for praising me and for your work!

Can you please post an example of the feature files and the feature class based on this change? I want to understand what this PR does and then I can decide what to do next. Thanks!

[miguelius]

Of course!

Say you have the the ComplexFeature where many business experts are working, with many aspects. While the feature has a set of steps, different combinations can be made. Of course you don't have enough coders.

You've written a small runtime where you just write the feature file in the folder Features. The runtime scans the features assembly and finds the Complex.feature file in the Features folder. It works like charm. But soon the analysts have problema sharing that only file.

In order to simplify their existence, it would be nice to have a couple of feature files associated to the same ComplexFeature class. For instance ComplexGroupOfScenarios1.feature, ComplexGroupOfScenarios2.feature and ComplexGroupOfScenarios3.feature would be files that describe scenarios for this common Feature. Each analyst now works in different file, preventing conflicts between them.

This fork allows you to share all the Given, Then, When and state within one ComplexFeature class, and allows users to write their scenarios in different Feature files. If they comply the pattern, the Runtime we'll find it.

Let's go to code:

[FeatureFileSearchPattern("Features/*Complex*.feature")]
class ComplexFeature : Feature {

  // series of given, when, then shared ammong scenarios and shared state within a concret feature

}

In the directory Features we have:

ComplexGroupOfScenarios1.feature file:

Feature Complex scenarios concerning some aspect
...
  Scenario 1
...
  Scenario 2
...

ComplexGroupOfScenarios2.feature file:

Feature Complex scenarios concerning some other aspect
...
  Scenario 1
... 
  Scenario 2
...

ComplexGroupOfScenarios3.feature file:

Feature Complex scenarios concerning some other creepy and super important aspect
...
  Scenario 1
... 
  Scenario 2
...

Analysts can write as many Complex*.pattern as they need without having any conflict.

I understand that Features shouldn't be thaaat big to have as many different scenarios. And you could also generate ComplexGroupOfScenarios1Feature, ComplexGroupOfScenarios2Feature and ComplexGroupOfScenarios3Feature classes extending Feature and the effect would be the same... Once we have compiled and redistritbuted the Runtime... That would be more work for your already-commited-to-another-project coders. This way with one common Feature class we can have many Files sharing the scenarios with the same Runtime.

The default pattern is ClassName*.feature. And it keeps the compatibility with FeatureFile Attribute. It also prevents loading it twice if it matches the pattern.

I'll write a test case describing a similar situation.

[miguelius]

Hi! We've added a couple of test cases.

1. AddFeature with two feature files: AddTwoNumbers.feature, AddNumbersTo5.feature
2. ComplexFeature with 4 feature files: Features/ComplexGroupOfScenarios1.feature, Features/ComplexGroupOfScenarios2.feature, Features/ComplexGroupOfScenarios3.feature, Features/Complex.feature.

Each feature file has different scenarios with an scenario name identifying the originating file.

Cheers!

[jclcbrain]

Hi,

I want to support this feature request.

We are using XUnit.Gherkin.Quick to create a small test-suite for domain-specific software. We want our non-coders (but still quite technical personel) to be able to create new .feature files without creating a new feature class, but utilizing an already existing feature class with generic step definitions.

The coders will compile and ship the test program with a feature class. Our test-writers are then able to create feature files to use with the feature class, without compiling.

As of now, the need to create a feature class and build the solution does not support this use case. This pull request seems create functionality to support our use case though. We are very excited about this.

[ttutisani]

Thank you all for your input!

@miguelius Did you push your commit? I don't see any such test cases when I open the files changed in this PR. Am I missing something?

I assume that you added those test cases under the Xunit.Gherkin.Quick.ProjectConsumer folder, but I don't see any changes under that folder. I only see changes to the unit tests and the Xunit.Gherkin.Quick itself.

[miguelius]

I've add an extra file to Xunit.Gherkin.Quick.ProjectConsumer/Addition_ForMultipleUseCases/AddTwoNumbersExtra.feature and the pattern search to Addition_ForMultipleUseCases/AddTwoNumbers.cs.

I've fixed an issue. When I added a class and a MissingFeature class was present, it assumed feature files associated by pattern were not implemented. So, it run the scenarios and also printed they were not implemented.

You can give it a try and if there is another issue, we'll gladly fix it.

[ttutisani]

I downloaded your code and ran the tests. I saw a strange thing - the tests under ProjectConsumer.Addition.AddTwoNumbers show duplicate results in the test explorer. That means the same test is executed multiple times. The only thing that is not duplicated is the new test that you added (AddTwoNumbersExtra). See the picture below. Please fix this to ensure the execution is fine and then I can review it.

If you try to pull the version before your changes, the same tests are not duplicated, so it looks like the duplication appears after your commits.

[miguelius]

I think I've fixed the bug. Or at least I see fewer test cases. The issues was when it was preventing to include the pattern and the explicit file name it compared by the string literal. Now, it uses the absolute path to compare filenames.

Please review it, and of course any other thing you may find, we'll be happy to fix it or improve it. Thanks for your review!

[ttutisani]

Thanks for fixing that! I see another strange behavior, is it me or for your is the same? In this PR, I can't find the "FeatureFileSearchPatternAttribute.cs" file. It is there in your fork but I can't find it in the PR, so I can't review it. Maybe you need to close and reopen the PR, I don't know. I hope you can figure it out and let me know when all files are in the PR.

[ttutisani]

Ah, never mind, I didn't realize this class existed before. Completely forgot. I will review the rest. Thanks!

[miguelius]

Thank you very much for review! We'll be working on it. Besides the implementation aspects mentioned above, have you found any functional Issue? If so, please, you are welcome to tell us.

[ttutisani]

Functionality looked good when comparing it before and after the change, so it's all good 👍

[miguelius]

Hi!

Fixed most of your comments.

Also changes the way it's used:

[FeatureFile("Features/*Complex*.feature")]
class ComplexFeature : Feature {

  // series of given, when, then shared ammong scenarios and shared state within a concret feature

}

Or in case of AddNumber:

[FeatureFile("Features/Add*.feature")]
class AddFeature : Feature {

// same here!

}

Classes are more or less the same than the original.

• FeatureClassInfo has a property to know wether you are working with file path or a pattern
• FeatureClassInfo has a matcher to determine if the file you're trying is treated by the feature. This allows MissingFeature discoverer to know if the file is a handled Feature File.
• The discover model was fixed to return a List.

Any other comment or suggestions is welcomed.

Cheers!

[miguelius]

Thanks for the feed back, Tengiz!

I've added both corrections! To prevent having two return points I used a dictionary in Discover method. Hope it's fine. If not, improvements are welcome!

Cheers!