Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running Feature files without compilation #132

Open
jonathanclausen opened this issue Sep 26, 2022 · 4 comments
Open

Running Feature files without compilation #132

jonathanclausen opened this issue Sep 26, 2022 · 4 comments

Comments

@jonathanclausen
Copy link

jonathanclausen commented Sep 26, 2022

Hi,

I have a use case where I would like to create a step definition class using Gherkin, then compiling and distributing it.
Then users of the program should be able to create their own .feature files and run the compiled distributed program in the terminal with their newly created feature files as input parameters.

Right now the feature files are tied up to test classes, therefore creating the need to compile every time a feature file is modified or created.

I'm looking for guidance in whether or not this is feasible to create with this library.

@ttutisani
Copy link
Owner

ttutisani commented Sep 26, 2022

I don't understand your request. Please help me understand. Let's go step by step.

I would like to create a step definition class using Gherkin

This is unclear. You cannot create a class using Gherkin. Gherkin can only describe a feature and scenarios in that feature.

Then users of the program should be able to create their own .feature files and run the compiled distributed program in the terminal with their newly created feature files as input parameters.

Do you mean you want to write feature (.cs) classes without writing the Gherkin (.feature) files? I don't see why you cannot do this, so I guess you are asking something else.

Right now the feature files are tied up to test classes, therefore creating the need to compile every time a feature file is modified or created.

This is not an accurate statement. You need to recompile the Visual Studio project only because during the build, the changed Gherkin feature file is copied into the output directory.

So, I am confused with this request, but I want to explain something, and maybe that helps.

  1. You can write cs feature classes without writing Gherkin feature files. You will need to mention the feature file name, but the feature file does not need to exist.
  2. You can run tests via terminal (command-line) using dotnet test command.
  3. When you run the tests, the feature class will try to find the feature file. If it cannot find the file, error is thrown, but the Xunit runtime swallows that error (don't ask me why, I don't know why they did so). So you can create a file later and place it in the output directory so that the file name matches the file name pattern that you specify on the feature class.

This way, you can write feature files later. Is that what you asked?

@jonathanclausen
Copy link
Author

Hi,
First of all, thanks for answering my question with such short notice. Maybe I was a bit too quick explaining what I want to accomplish.

I have written a feature implementation class with very generalized steps. Such as [Given("field {some_field} is {some_value}")] and [Then("field {some_field} must be {some_value}")] etc. I will very rarely have to change the feature implementation class.

Now, I want business architects without programming skills to utilize the different step definitions of the feature implementation class and write their own tests in Gherkin .feature files, utilizing my feature implementation class. I cannot require these people to use Visual Studio to run tests, so I'm researching whether or not there is a way to run Gherkin .feature files without Visual Studio. You mention dotnet test, but as I see, this also rebuilds the solution, and requires dotnet to be installed, which is not wanted.

Ideally, I would like to distribute a feature implementation class as a program, perhaps named something like testing-program and have the user be able to run the program with the Gherkin feature-file path as parameter, like so: testing-program.exe {path-to-feature-file}.

The result of this would ideally be visually like the result of dotnet test command when run from the terminal, where it is possible to see which tests passed and failed and so on.

I hope this provided a better understanding of what I'm trying to accomplish.

@ttutisani
Copy link
Owner

I'm researching whether or not there is a way to run Gherkin .feature files without Visual Studio.

There is, that is dotnet test.

You mention dotnet test, but as I see, this also rebuilds the solution, and requires dotnet to be installed, which is not wanted.

  1. dotnet test will rebuild solution if you just type dotnet test. If you type dotnet test <test dll>, it will run tests in that project's DLL output. When you write tests under a test project, when you build that project, it generates an output DLL, just like any other project generates output on build. You need to navigate to that folder and run the command there by specifying the DLL name in the command.
  2. Yes, it requires dotnet installed. There is no way around it. Dotnet is a runtime that is required by anything that is written in any of the dotnet programming languages. So, there is really no way around it. If you cannot install dotnet on your end users' machines, then you should not write code that compiles using dotnet compiler.

Ideally, I would like to distribute a feature implementation class as a program, perhaps named something like testing-program and have the user be able to run the program with the Gherkin feature-file path as parameter, like so: testing-program.exe {path-to-feature-file}.

I see two options:

  1. Use a filename pattern and location in the feature class attribute (FeatureFile("...")) and tell your users to place their file based on that convention. After that, the end user will need to run the dotnet test as I showed above.
  2. Write a wrapper program that does that for the end users. e.g., it must be fairly simple to write a CMD batch file that takes the feature file name as a command line argument, then copies that file into the test project DLL output location, and then runs the dotnet test command as I explained above. This way, users will not need to name the file based on convention and will not need to place it in the predefined location. The wrapper script will do that. Users can execute that CMD file as you want by passing the feature file as an argument.

I hope this helps.

@ttutisani
Copy link
Owner

If the above comment addressed your concerns, please respond and close this issue. Otherwise, please explain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants