TestApi

This post recounts my journey to understand tests data arrangement from before my blogging days. This exploration cemented key lessons in reusability and composition.

The TestApi pattern helps decouple tests from our system and enables more stable and reusable tests. I’ve shown how I use the pattern in F#. Now here’s a similar example in C#.

I previously compared the tradeoffs of Gherkin-based and TestApi-based behavior tests. Recently, I realized there is a simple in-between solution: TestApi with Gherkin-style names.

I’ve been exploring large-scale formal development practices, and realized acceptance tests may be the best way for developers to encode expectations for other developers.

I previously wrote on the Test API behavioral testing in F#. More time and thinking has brought about a few key improvements, making the pattern both more concise and standardized.

I’ve use Test API for behavior testing for more than a year now, and to great effect. I expected my recent experience with Gherkin to be similar, but found the two BDD techniques to be surprisingly different. Here I’ll contrast the two methods to highlight their distinct value.

I finally got hands-on experience with Gherkin, the common language for Behavior-driven Development (BDD). Getting started was more of a struggle than I anticipated. Here are solutions to some of my main hangups.

Paul’s Test Api permanently changed the way that I test. It’s only natural I’d want to bring the pattern over to F# with me. Here’s how I did it and a few extra testing tips for F#.

A friend of mine, Paul Spoon, wrote a delightful article about using the Anti-Corruption Layer pattern as a tool for more stable tests. I tried the pattern with skepticism, and will now never go back. Let’s take a brief look at the pattern then dive into the benefits I’ve experienced.