Git Workflows are so highly talked about on the internet - I would guess there are tens of thousands of blog posts, articles, and discussion threads on the topic. Everyone seems to have their own opinions on why your workflow is slowing you down or why its problematic - but no one talks about the fact that, like most tools, it needs to work for you and your team. I feel the same way about agile and scrum - so many people like to tell you how to do it, and like to tell you that your way is bad, but that way might not work for you at all.

Knowing how the test layers all play together is one thing, but getting them all working together turned out to be a little bit more difficult.

First - the application we were testing required a few different styles of scenarios. We had the obvious API tests, but this application also worked with not only external REST APIs, but also Redis, and AWS infrastructure as well. We needed to be able to controll all of these things for our component tests, but also wanted to make it quick and easy to use. MockServer was our tool of choice for the other REST APIs - it just works, and does what it says on the tin. For AWS, we always use Moto to do our component testing. It is so much faster and cheaper than spinning up and down real AWS infrastructure, and for everything we’ve used so far, it works perfectly.

At work, I have a cohort, whom with I am convinced I share a brain. We recently embarked on a project to redesign and rewrite one of the core pieces of the application stack that we work one - it manages a hands-free modelling pipeline, based on configurations. A user of our app can make a configuration change, and this component reconciles those changes, runs the necessary background modelling tasks, and figures out when the model is ready to be used in production.

At its core, it is a state machine. We designed it like that at the start. However, through time and added features, it wasn’t implemented as a state machine, and became pretty unruly to debug or extend. We were adding a lot of new features in our upcoming release that just couldn’t be made to work in the existing code base - it was written too rigidly to accept that many things can happen from a singular “state”, each taking their own time - and started a rewrite into a full state machine. We’re a C# and .NET shop, so we found dotnet-state-machine/stateless, and it worked amazingly.

While we were doing the rewrite, however, we wanted to make sure we were not adding new bugs or regressions. The original codebase had only the bare minimum of automated tests, so we started with expanding them first.

Let’s talk about testing layers, how they interact, and how we used them to ensure our rewrite was a success