Generating .feature.cs files and running them without using dotnet CLI

[Aiden Sobey]

Hi All,

My team is looking to utilise SpecFlow for some automated UI testing. We already have a solid framework and test base built up, but are trying to optimise our processes. Particularly for our Business Analysts.

The work flow we are trying to achieve is similar to this stackoverflow post. Unfortunately the solutions posed in there are extremely old and no longer relevant.

In this case we would have our step definitions built and accessible as .dll files, what we would like to do is:

1. Modify a .feature file
2. Generate the behind code file for that feature without using 'dotnet build' or any kind of IDE integration. Ideally just an executable we can run.
3. Execute that newly generated behind-code file. Again without the 'dotnet test' CLI or any IDE being involved.

Is this possible? Searching the web shows mixed answers with most of them very old.

Thanks in advance for any responses.

[Allen Toole]

Hi Aiden,

 

I’m sure if I understand your question completely, but I’ll give an alternate suggestion:

 

Questions:

1. If you utilize dll(s), how do you manage having the most current code executed or know if your dlls represent current code base?
2. If you test across environments that potentially could have different versions of the code, how would you manage?

Now, my recommended approach:

1. Write feature.scenarios.stepsdefinitions.steps (to implement your existing code)
1. Use appropriate tagging on feature file and feature scenarios
2. If using “Scenario Outline”, organize examples and associated tags
3. You may find that some refactoring of existing code may be necessary
2. Build out a flow that pulls from you source repo based on specific branch, this could be a default branch that can be overridden in special conditions as needed.
3. Build you code and generate an executable that contains the tests
1. Build considerations

                                                               i.      Create a series of *.srprofile and *.runsettings to use for filtering the tests that you want to run based on tag associations.  This is where you have the freedom design/organize based your intentions

                                                             ii.      You will probably need to create environment variables to help simplify paths when referencing build components.

I hope this makes some sense and is helpful.

 

Kind regards,

Allen

 

Sent from Mail for Windows 10

--
You received this message because you are subscribed to the Google Groups "SpecFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to specflow+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/specflow/40f771c9-60d5-4211-b465-50919e6437d2o%40googlegroups.com.

 

[Aiden Sobey]

Hi Allen, thankyou for taking the time to reply.

I'll respond to your questions first-

1. We have a desktop application used by the Business Analysts (BAs) which manages the version and updating of the dll's. We can ensure they are always up to date and requires no overhead from the user.
2. Our specflow setup reads in from a config file, so environment/login can be specified on a per-user or per-test basis. We find this is working well for us currently.

The approach you have outlined is quite similar to what we do (excluding the .srprofile and .runsettings, we have our own way of handling that). The issue is this requires BAs to install git on their machine, have an understanding of branches, pulling etc. We're really trying to avoid that.

Thank you again for the response, I really appreciate your input. But what I'm really trying to achieve here is the ability to generate and run Specflow tests without having git or .NET SDK installed.

Thanks,

Aiden

To unsubscribe from this group and stop receiving emails from it, send an email to spec...@googlegroups.com.

[Eliezer Cazares]

You can do all of that with Azure Pipelines but that would depend on whether you are using it already or not.

--

You received this message because you are subscribed to the Google Groups "SpecFlow" group.

To unsubscribe from this group and stop receiving emails from it, send an email to specflow+u...@googlegroups.com.

[Aiden Sobey]

Unfortunately we do not, and it would be hard to convince management to adopt it just for this. Thankyou anyway though!