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.

I’ve been using Go for a year now. We started with developing a command line tool to use within a CI/CD pipeline which handled user authentication and provide an easy way for a user to interact with one of our GraphQL APIs. The experience using Go has been great. New team members sometimes find the learning curve with scala a bit steep and the syntax unfamiliar. Looking for a way to reduce friction with ramping up new team members, I started exploring Go.

Recently I needed to containerize a Gatsby site and deploy it to a kubernetes cluster. The cluster had an ingress controller that mapped the /docs path to the Gatsby service. I just wanted to take a quick minute and document the process here. I utilized the pathPrefix in Gatsby so that the service would host the website at the /docs path. const config = { gatsby: { pathPrefix: '/docs', ... I then created the following Dockerfile to build the image that would be deployed to kubernetes.

Alright, just completed migrating the blog to gatsby from wordpress. I’m looking forward to getting back into writing and posting on a regular basis. Stay tuned for more content….

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.

Recently I had to set up an Oracle 12c database in a container with test data to be used during testing and development. This post is just a quick documentation of that process. The developer tier for Oracle Database 12c Enterprise Edition is available on Docker hub. It’s available through the store, but is free of charge. On Docker hub, you’ll need to click on the ‘Proceed to Checkout’ button, agree to the terms of service, enter your contact information, and click on the ‘Get Content’ button.

Recently I included Kamon’s instrumentation tools into an Akka project. I posted the sample project on github. I’ll do a quick walk through of the process in this post along with my initial impressions of Kamon. I started with the documentation in Kamon’s plain application installation guide. I added the latest Kamon bundle in my build.sbt. This includes all the instrumentation available in Kamon. libraryDependencies += "io.kamon" %% "kamon-bundle" % "2.

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.

This is a quick introduction to setting up an asynchronous test of akka actor using TestKit and ScalaTest. With the Akka 2.6 release, Akka Typed becomes the default and the actors we’ve been using prior to the 2.6 release are now “Akka Classic.” I’ll be covering Akka Typed in some forthcoming posts. But for now, I’ll use Akka Classic to do a quick example of the basic usage of TestKit. I’m going to demo this using a really simple actor that replies to a Ping message with a Pong.

ScalaTest provides domain specific language to allow you to write behavior functions to share the same tests amongst different fixture objects. What does this mean? If you are repeating the same tests in multiple specs, you can create some very readable and compact syntax to encapsulate and reuse the tests. Create a function that encapsulates those tests. For most of the TestSuites, you use “behave like” to call that function and execute all the tests.