Unit test your server-side JavaScript with Spock

Java 8 was recently released with Nashorn – a JavaScript runtime for the JVM. There are many reasons you may want to use JavaScript in your JVM application; for example, validation logic or template code that can be used on both the client and the server.

I am going to show you how to unit test your JavaScript code using Spock. This Groovy-powered specification framework is powerful and expressive, and integrates nicely with existing Groovy (and Java) codebases with its JUnit test runner.

So why should you test your JavaScript code with Spock? I can think of a few reasons:

1. Tests integrate with your existing Spock / JUnit-powered test suite, reporting, and IDE.
2. If your JavaScript uses Java APIs, you have them available for use.
3. You get all of the things you love about Spock: power assertions, data-driven testing, mocks, and most importantly: readable tests.

Red, red, red, red, green, refactor

Let’s write our test first:

And let’s stub out our function:

As you would expect, we get a failed test. Let’s implement that:

And here you get the power of the Groovy power assertion. Rather than a generic “Expected James, got undefined”, you get this:

Let’s change “first” to “firstName” and “last” to “lastName”:

And we have a green, passing test!

Data-driven testing

As with any other Spock test, you can use the data table to easily repeat tests with various values:

Interactions

What about interaction? Suppose we have a JS function that needs to call a callback function. We can pass a closure to stub out the behavior:

But we’re really not validating the interaction. We trust that it called the stub, but it’s not ideal. Instead, let’s try a Spock Mock:

We can also mock out functions that would normally be defined elsewhere, such as alert():

You can pass any implementation of an interface that is annotated with @FunctionalInterface: Consumer, Predicate, Supplier, etc. I chose Function here because it is the most flexible.

Resources

There you have it. I love Spock, and I’m learning to appreciate JavaScript (it’s what you might call an “arranged marriage”). I put the source from this blog post on Github so you can play around with it yourself. Please comment here if you have any questions!

• Nashorn blog
• Nashorn – The Combined Power of Java and JavaScript in JDK 8
• How Java 8 handles JavaScript

About the Author

David Norton profile.

David Norton

Director, Platform Engineering

Passionate about continuous delivery, cloud-native architecture, DevOps, and test-driven development.Passionate about continuous delivery, cloud-native architecture, DevOps, and test-driven development.

  • Experienced in cloud infrastructure technologies such as Terraform, Kubernetes, Docker, AWS, and GCP.
  • Background heavy in enterprise JVM technologies such as Groovy, Spring, Spock, Gradle, JPA, Jenkins.
  • Focus on platform transformation, continuous delivery, building agile teams and high-scale applications.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]
Using Spring Beans in a Kafka Streams ExceptionHandler
There are many things to know before diving into Kafka Streams. If you haven’t already, check out these 5 things as a starting point. Bullet 2 mentions designing for exceptions. Ironically, this seems to be […]