In response to a recent feature request aimed at bolstering the functionality of our B2B application, we embarked on a journey to support an OAuth2 client credentials flow for our customers authentication use cases. Leveraging our existing use of Azure B2C as our identity provider, we undertook the challenge of enabling users to benefit from this authentication mechanism. Our solution hinged on the capabilities of the MS Graph API, which provided the backbone for our implementation.

In this article, we’ll walk you through the process of taking an Azure Function created using Terraform and deploying it effortlessly using Azure DevOps. We’ll go step-by-step through creating the Azure function handler in Go and deploying it via an Azure DevOps pipeline. In the starting point for this function, our cloud engineer has already created the function using Terraform with the app_settings having a FUNCTIONS_WORKER_RUNTIME of “custom”. A valuable reference for creating an Azure Function in Go or Rust is available at https://learn.

I had previously migrated this blog to Gatsby Cloud from WordPress. The process of crafting a blog entry as a markdown file and seamlessly publishing it to Gatsby Cloud by simply pushing it to Github proved to be a significant time-saver compared to managing a WordPress site. In February 2023, Netlify acquired Gatsby and in August, announced the sunset of Gatsby Cloud. This left me in search of a new platform or home for my blog.

Here’s a scenario I’ve come across multiple times when considering the database calls that your application makes while you’re writing your test code. In this example, let’s assume we’re creating some sort of API (rest, GraphQL, gRPC, or suc). And let’s assume we are persisting our data in some sort of database, maybe a relational database, a NoSQL data, or even a graph database. When unit testing the code in your infrastructure layer that handles persistence of your data, mocking the database in those unit tests makes sense.

In the last post, I put together an example of utilizing a CI/CD tool like CircleCI to run your tests when new code is committed and provided an example of seeting up some basic test and code coverage reporting. In this post, I’ll walk you through updating your CircleCI configuration to incorporate some more robust code coverage reporting using Codecov. Since I’m already using Github, integration with CircleCI will be pretty simple.

One last piece to discuss in this series on using Cucumber and Godog is reporting. When you’ve collaborated with your users and created a great suite of features to test the behavior of your system, you’re likely not going to be only running your features from your favorite IDE or the command line all the time. You’ll have some sort of CI/CD pipeline to deploy your new functionality regularly. As part of that pipeline in addition to your unit tests, you’ll be running your features to validate your new functionality behaves as expected and none of the previously working functionality was broken.

In this entry in my series on Godog I’m going to cover the new Rules keyword, introduced in Gherkin 6. The Rules keyword is useful in example mapping. There is a great article explaining this new syntax at https://cucumber.io/blog/bdd/gherkin-rules/. Instead of being restricted to Features that have Scenarios, you can do your example mapping such that your Feature has one or more Rules, and those Rules are then illustrated by Examples (or Scenarios).

In part 2 of this series we introduced several hooks, including ones that could run before each scenario to handle set up for each scenario or scenario outline example in the feature. That is a great place to do any setup work to make sure that each scenario starts with a known state. But what if the business user that we’re collaborating with has some needs to perform some work/setup before each scenario?

As we ended the previous post saying that we were going to put the focus back on the feature file and collaborate more with our business users, we’re going to cover the use of example tables, data tables, and doc strings. As we talk with our business users, we discuss that deposits and withdrawals can happed concurrently. Checks written from an account are cleared by other banks at the same time the owner makes deposits/withdrawals electronically, or payroll direct deposits are made, or ATM transactions occur, etc.

Picking up where we left off in the last post, I wanted to put forth another approach to managing the state between steps within a given scenario. We’ll call it AccountTestState. In this approach, I’m going to create a struct to track any variables that I want to create or assign in one step and then use or validate in a subsequent step in the same scenario. I’m also going to create a function to reset that state, as we’ll want to start each scenario with a clean state.