In this blog post, we’ll explore how to use the IParsable<T> interface to build a generic Reqnroll value retriever and comparer. We’ll start by creating custom value retrievers and comparers, then develop a reusable solution with generics, and finally, we’ll use reflection to make it even more generic. (This solution also works for its predecessor, SpecFlow, when using .NET 7 or higher.)
Automated testing is an essential part of software development, and determining the appropriate scope for your tests is crucial. This is also true when automating Gherkin scenarios with SpecFlow (or Cucumber). In this post I explore the different levels of the test pyramid and describe my preferred level for SpecFlow tests.
In a previous blog post I wrote about a trick on how to remove technical ids from Gherkin scenarios while still using technical ids in the step definitions. The proposed solution worked well for the given scenario, but not for other cases. In this post I look at several approaches on how to solve this issue.
I use Gherkin scenarios to describe the functional specifications of my software and SpecFlow to automate these scenarios as tests. Usually there will be a couple of scenarios describing the happy path of the feature I’m building but also some scenarios concerning failures. In this post I’ll show my solution how to handle failures in the form of exceptions with the Driver pattern.
Gherkin scenarios in Specification by Example are used to describe the functional requirements of your software. They should be readable for the team and also for the business that uses the software. Technical ids don’t have a place here. They’re usually included in scenarios for test automation purposes but make the them harder to read. So, what to do when your code requires a technical id?
