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

Who uses Xunit.Gherkin.Quick and why? #75

Open
ttutisani opened this issue Apr 25, 2019 · 4 comments
Open

Who uses Xunit.Gherkin.Quick and why? #75

ttutisani opened this issue Apr 25, 2019 · 4 comments
Labels
Discussion Ongoing discussion, gathering thoughts

Comments

@ttutisani
Copy link
Owner

ttutisani commented Apr 25, 2019

If you use "Xunit.Gherkin.Quick," please post here information around who you are (company/GitHub project name), how you use it (use case), why you like it (deciding factors), and so on. Everything is optional, provide as much or as few details as you want.

This discussion can help others decide to use or not to use the framework. Also, with more feedback, more people might be interested in considering this fantastic framework. As a result, the framework will be more popular, better tried through more use cases, with better quality, and more features too! Everybody benefits!

Thank you for your time!

@ttutisani ttutisani pinned this issue Apr 25, 2019
@glassenbury
Copy link

My name is David Glassenbury. I work for a company called Trimble in a joint venture with Caterpillar. I am based in New Zealand. We decided to use xunit.gherkin.quick as we converted to c# dotnet core and run them in linux docker containers on jenkins pipelines. We have one windows docker container as well. The tests are in docker containers in vsts and jenkins. The results are posted back to both dashboards.

The project seems to be talking years to convert this. It took about a 2-3 months for one person to convert approx 3200 tests for services and UI. With the UI we use selenium. These are run of a headless chrome browser in a linux docker container. In vsts we multi thread test runs this using amazon eks. We will start up to 12 parallel test runs. This reduces the whole test run down to 30 minutes for 2300 UI tests. Our main service is a windows dotnet core 2.2. We multi thread just using a runsettings file and mstest. 640 tests take around 3 minutes.

Once converted I think this framework is a lot more lean. The project is clear and the one to one link with feature /steps is clearer to me. With specflow we seem to constantly getting the feature and feature.cs files out of sync. This wasted a lot of time.

@csurfleet
Copy link
Collaborator

Hi, I'm Chris Surfleet, I'm a Lead Developer with Carfinance247.co.uk. We have adopted XGQ for all of our new system integration projects. These are all .net core projects being deployed to docker.

I've created a test framework combining XGQ, Xunit's test context pattern and the .net core TestServer. This allows us to easily do most-of-stack tests without forcing less experienced team members to worry about the complications. I've found the simple link between the feature files and the tests easy to work with generally, and we make extensive use of the PicklesDoc integration - all our builds push pickles sites out so that our stakeholders can see the state of the development.

I'm still struggling to get stakeholders working via specification by default (rather than going through us all the time), but that is nothing to do with XGQ - as usual the hardest thing is people not tech!

Going forward, I'd love for the integration with the VS test explorer to get tighter - there is often lag, or the need to 'run all' to get things to show up. I'm aware this is probably not something we can do a huge amount about though - hopefully the VS team will work on the XUnit integrations!

@richard-haslam
Copy link

My name is Richard Haslam I am a QA Lead for a Health Insurance company in the UK. I had been using Specflow for a few years. A recent strategy has been to allow out tests to be platform agnostic so we can choose the cheapest cloud platform to use and move between them easily. This meant we needed to be able to build and run on Linux as well as Windows, so we have switched to dotnet core and had to look for an alternative to Specflow. Enter Xunit.Gherkin.Quick!

I use this for running both Selenium tests and API testing with RestSharp.

@ttutisani ttutisani added the Discussion Ongoing discussion, gathering thoughts label Jul 30, 2019
Repository owner deleted a comment from wcdeich4 Nov 24, 2020
@ttutisani
Copy link
Owner Author

ttutisani commented May 6, 2022

It's time that I share my story too.

My name is Tengiz Tutisani. I am the author of this framework, and I am also the user of it (that is why I created it in the first place - because I needed it).

Archipeg uses Xunit.Gherkin.Quick to run integration tests written in Gherkin. Archipeg was built with the test-first approach ground-up and 100% test covered. That means I follow ATDD (Acceptance Test Driven Development) and it just rocks! These integration tests have saved time and trouble many times! I'm happy that Xunit.Gherkin.Quick exists 😊 I picked this framework not because I authored it but because I love how lightweight and editor agnostic it is. Put a feature file, write up a class with implementing code, and there you have it! This simple flow is what fits perfectly with fast-paced software development processes.

Archipeg is a digital architecture software (i.e., Enterprise Architecture, Solution Architecture, Application Architecture, you name it). It allows capturing, analyzing, and sharing various digital architecture-related information and assets across entire teams and organizations. It is a tool that is used by EA, Solution Architects, and everybody else who wants to learn or share architecture knowledge with others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Ongoing discussion, gathering thoughts
Projects
None yet
Development

No branches or pull requests

4 participants