Endjin - Home

Testing

Using complex objects in BDD Scenarios with SpecFlow

by Jonathan George

During our projects at endjin, we often find ourselves evangelising Behaviour Driven Development, and specifically SpecFlow. In this post we look at a technique for defining complex test data objects in your Gherkin feature files, which we’ve also made available via the endjin-sponsored Corvus.NET project.


If you use Azure Functions on a regular basis, you’ll likely have grappled with the challenge of testing them. Even now, several years after their introduction, the testing story for Functions is not hugely well defined. In the final post in this series, we show how to ensure specs written using Corvus.SpecFlow.Extensions can run as part of your build pipeline.


If you use Azure Functions on a regular basis, you’ll likely have grappled with the challenge of testing them. Even now, several years after their introduction, the testing story for Functions is not hugely well defined. In the fourth of this series of posts, we look at how configuration can be supplied from your tests to the functions apps being tested.


If you use Azure Functions on a regular basis, you’ll likely have grappled with the challenge of testing them. Even now, several years after their introduction, the testing story for Functions is not hugely well defined. In the third of a series of posts, we look at using classes in the Corvus.SpecFlow.Extensions library to run functions apps via scenario and feature hooks.


If you use Azure Functions on a regular basis, you’ll likely have grappled with the challenge of testing them. Even now, several years after their introduction, the testing story for Functions is not hugely well defined. In the second of a series of posts, we look at using step bindings provided by the Corvus.SpecFlow.Extensions library to run functions apps as part of your SpecFlow scenarios.


If you use Azure Functions on a regular basis, you’ll likely have grappled with the challenge of testing them. Even now, several years after their introduction, the testing story for Functions is not hugely well defined. In the first of a series of posts, we look at some different approaches to testing your functions apps, and introduce the Corvus.SpecFlow.Extensions library.


Along with several of my endjin colleagues, I attended NDC London in January this year – here’s a run through of the sessions I attended on Day 3 and my thoughts. This final day was a mixed bag, taking in talks on drumming and AKKA.net, as well as something a bit more close to home – a session from endjin’s own Jess Panni and Carmel Eve on our recent project for OceanMind.


A good test suite should validate behaviour across your code base, testing as many edge cases as reasonably possible. A common “edge case”, is passing a null value when a value isn’t expected to be null. In Specflow, all values used in scenario examples are treated as strings, so it isn’t possible (by default) to pass in a null value. However, using “Step Argument Transformations”, we can achieve the desired behaviour. Read this blog to learn how this can be implemented.


This is a quick guide to setting up cucumber JS in Visual Studio with grunt.


One of the great benefits of using SpecFlow is that it allows you to write your specifications in a human readable format. Learn how you can create reusable step argument transformations to apply custom transformations to your parameters, so that you can keep your specifications easy to read.


There’s a lot of documentation available around NuGet and how to create/publish packages, etc. But when I looked for a simple step-by-step guide on how to test a package locally, I couldn’t find any.