Chaos Engineering is a hot topic and very cool to dive into. But
knowing where and how to start can be a challenge. In this series, I
want to demonstrate different sides and technologies you can use. In
the first post: Simmy, a package to inject different kinds of chaos in
a .NET project.
It can be a challenge to implement new frameworks or tools in your daily life. Often it takes time to find out the quirks and best practices which can take time and even lead to doubts and abandoning frameworks. I have been using SpecFlow for a while now and I keep finding new ways to tackle issues and get cleaner code behind the specs (I am still having trouble creating clean & clear functional requirements though).
One of the things I keep bumbing into is using settings and sharing code between different specs. In the following example I will explain my latest find: using xUnit fixtures to get test settings and reusable api clients for multiple tests.
SpecFlow is a tool which can be used to describe test scenarios and automate the tests. Although I have been using SpecFlow for a while now I never used it for advanced examples where time might be an issue. Lets show a simple example scenario first. A scenario, written in Gherkin, looks like this:
Scenario: Add simple item with due date
Giventhe user enters "wash my car"Andthe user adds a due date of "1-1-2022"Whenthe user saves the item
Thenthe item "wash my car" is added to the list
Andthe due date is "1-1-2022"
This scenario is easy to implement, the item will be added and stored. That’s it. Easy to verify, no delays, straight forward. But what if you have some microservices with a queueing mechanism? A scenario where data will be queued before processing so we can’t exactly know when the data is processed?