How to make working with Specs2 much easier

Hi. Specs2 is one of the most popular Scala libraries for testing, but definitely not a simple one. That’s why I’ve decided to create a blog post with a few tricks on how to make working with Specs2 much easier. The examples are 100% artificial, but their purpose is only to demonstrate the capabilities of Specs2.

Basic example

Ok, so let’s start with a basic example.

Pass the data into the tests

We can do this in (at least) two ways. Just pass the data as regular variables:

or pass them as a scope

The first option is very straightforward and works well for small tests, but is impractical for bigger ones or when you want to (for some reason) share the values.

Implement custom Setup and Teardown

Now let’s say that we need to perform some important operations before and after every single test case. How can we achieve that? It’s simple. We can use Contexts again.

First of all, we need to create a helper for the local setup and Teardown. We can do it like this:

now we can do

Implement custom Setup and Teardown for all test cases

The above example works well, but only for single test cases. So now let’s write something for the whole test suite.

Random thoughts

  1. Watch out for the static configuration and methods, they might cause tests to break from time to time.
  2. When using Specs2, try not to mix sub-packages. Some mixins from org.specs2.mutable might not work with those from org.specs2.specification and so one. Even worse they might just fail silently.
  3. As you have probably already noticed, Contexts can be classes, traits and objects.

Do you like this post? Want to stay updated? Follow us on Twitter.

Read also:


Patryk Jażdżewski

I'm a software consultant always looking for a problem to solve. Although I focus on Scala and related technologies at the moment, during the last few years I also got my hands dirty working on Android and JavaScript apps. My goal is to solve a problem and learn something from it. While working with teams I follow "The Boy Scout" Rule - "Always check a module in a cleaner state than when you checked it out". I think this rule is so good, that I extend it also to other aspects of software development - I try to improve communication patterns, processes and practices ... and all the things that might seem non-technical but are vital to success.

Latest Blogposts

28.06.2022 / By  Jorge Vasquez

A Prelude of Purity: Scaling Back ZIO

ZIO World is the leading annual global ZIO-based event created by Ziverge. The event aims to inspire new trends, promote innovation, and reveal significant developments across the ZIO ecosystem. ZIO World invites developers to share their expertise in using ZIO. This year, ZIO World hosted Scalac developer and ZIO contributor Jorge Vásquez. His presentation focused on […]

20.06.2022 / By  John Jimenez , Francois Armand

Functional Programming vs OOP

As a young, bright-eyed, bushy-tailed engineer starting my career at NASA in the 90s, I was fortunate enough to develop engineering-oriented software that modeled the different parts of the International Space Station. The million-line codebase was based on objects. Almost every part of the space station was represented as an object, from the overall segments […]

14.06.2022 / By  Łukasz Gajowy

OpenTelemetry from a bird’s eye view: a few noteworthy parts of the project

OpenTelemetry provides you with a set of tools, integrations, APIs, and SDKs in different languages to more easily increase the observability of your application. We figured that, since we’re working on an OpenTelemetry agent extension called Mesmer, we could show you the project from a developer’s perspective and point you to the parts that could […]

Need a successful project?

Estimate project