BDD

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 recently read Mark Seemann’s post on how Testability is the Open-Closed Principle. This helped me realize the approach to testing directs the kinds of flexibility in our system, and behavior-based testing pushes the right kind of flexibility.

I previously wrote on how acceptance tests can streamline communication between developers and teams. I’ve been thinking about practical enactment of such a scheme and surfaced some interesting ideas.

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.

Learning functional programming has included significant quality time with Type-Driven Development and property-based testing. These paradigms highlighted a gap in my previous testing techniques. It led me to better classify types of communication errors between customers and code, and the toolset for addressing each type.