Dear BDD Addicts,

I hope you are fine & busy. I’ve read an article about the decreasing demand for developers. It’s easy to get depressed by reading such articles (I usually skip them), but this one had an interesting sentence at the end that said that skilled and up-to-date people in tech are still in high demand. These are the times to learn something new! One of the evenings I’ve read an article that triggered me an idea how to solve a problem that I was puzzled with for more than a year now in SpecSync (the test synchronization tool I’m working on most of my time). And a week later I had the new improvement implemented and tested and I’ve even gathered a couple of other ideas as well.

So this month I have selected articles from a broader range of test automation topics. Will they give you inspiration? Let’s figure it out! …and let me know your feedback about them by dropping a mail to bddaddict@specsolutions.eu.

Here is the monthly dose.

---

[Reqnroll] Time to Reqnroll

In the last newsletter, I have mentioned about the initiative I’ve jumped into this year: rebooting the SpecFlow project as Reqnroll. It has been a very busy month, but at the same time very motivating. I absolutely did not expect so much enthusiasm. If you check out the GitHub discussions of Reqnroll, you will see that within a month there have been vivid conversations, people working on issues, implementing new features and even started on new architectural improvements. So let me just use the words by Justin Holsgrove: Time to Reqnroll!

Time to Reqnroll (Justin Holsgrove)

---

[Cucumber] Playwright runner for Cucumber?

One of the most common questions for Cucumber/SpecFlow/Reqnroll is whether Cucumber/SpecFlow/Reqnroll supports Selenium/Playwright/<random tool name>. And the answer has always been that these BDD frameworks give you an automation shell to describe your expectations with BDD, but they don’t influence you how you will automate them, so you can do that with Selenium, Rest Assured or whatever else that you would like to use.

But times are changing. If you would look at the recent testing tools, their key features have changed. Whether they are able to do an action on an interface (e.g. automate a browser action) is not the key selling point anymore. That is a necessity. The homework that has to be done. The difference is how they integrate into the development process: how the developers can contribute, optimize/distribute the test execution and how they can share their results with the other stakeholders. In this new world, having a standardized way of test execution might turn from a benefit to an inconvenience.

This phenomenon becomes visible in the context of Playwright support of Cucumber. Cucumber of course can execute Playwright tests (just like Selenium ones), but this is not anymore what people need – they would like to use the execution ecosystem provided by Playwright too as it becomes clear if you check this GitHub ticket. In case of Playwright  and Cucumber, a solution emerged thanks to Vitaliy Potapov that uses a smart solution to achieve the goal: generating Playwright tests from Cucumber scenarios. Inspirational.

playwright-bdd – Why Playwright runner? (Vitaliy Potapov)

---

---

[API] API documentation is a specification

In my work I often need to learn and use new APIs from a wide range of vendors. Over the years I have learned what makes a good API documentation stand out from less-than-good ones. One of the most important factors were for me to have examples (you can tell, I’m a BDD addict…), but there are others things as well.

I was happy to find the article from the Karate labs team about their guidelines on how to make good API docs. Spoiler: the examples are in!

7 Errors You Must Avoid In API Documentation (Karate Labs)

---

[Contract Testing] Pragmatic Contract Testing

Contract testing is an undervalued topic in my opinion. With the emerged need for distributed applications and data processing the number of interfaces we introduced has grown significantly and this causes an exponential increase of testing need (“everything” needs to be verified against “everything”). The name of this testing approach got somewhat strongly combined with the product Pact. This is good, because Pact provides a ready-to-run solution and architecture, but at the same time it increases the myth factor (Pact is a complex piece of solution itself).

The article by Garrett James Cassar might help demystifying contract testing, even if you keep use Pact after reading it. I like that it focuses on the development process instead of the features… familiar?

Contract testing — Without Pact (Garrett James Cassar)

---

[API] Design ideas for your API testing solution

Focusing on the development process for testing is not only important for tool integrations and pragmatic solutions that we mentioned above, but it can also be an important factor for designing our testing solutions as well.

The article by Justin Scroggins is a good example of how to build up a testing solutions based on some development process (including maintainability of course) goals. Inspirational for you as well?

Creating a Modular API Testing Library using Playwright and Typescript (Justin Scroggins)