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.

Over the next few posts, I’m going to cover the various features of Godog. In the past I’ve found success using behavior driven development (BDD) in projects, part of which involves collaboratively documenting expected system behaviors using a syntax like Gherkin. Taking that approach, I’ve used tools like Cucumber-JVM or Cycle. Godog is the official Cucumber BDD framework for Go. It has not yet reached 1.0.0, but already is incredibly useful.

Writing tests of collections in ScalaTest is easy. In this post, I’ll cover a few of the very simplest cases. Of course the simplest case is equality, something along the lines of validating two collections are equal. "using equality" must "validate collections" in { val expected: Seq[Int] = Seq(1,2,3) Seq(1,2,3) mustBe expected } But the limitation of using equality if of course besides the same elements being in both the actual and expected, the number and order of the elements must match.

Using Selenium in Scala is pretty easy. For this demo, I am using a remote browser which I made available by using the standalone-chrome docker image. To start a container locally, you can simply run the following. docker run -d -p 4444:4444 -v /dev/shm:/dev/shm selenium/standalone-chrome I’ll be using Selenium 3.141.59, which is the latest stable version at the time I wrote this post. Version 4.0.0 is in alpha, and I will be sure to be checking that out really soon.