Table of Contents
- Getting started
- First steps
- Adding Given/When/Then behavior (and ‘And’)
- More on Given, When, Then, and And
- Add more tests within ‘describe’
- Testing Option/Some/None in a BDD test
- Nesting describe blocks
- Using ‘before’ and ‘after’
- Mark tests as pending
- Temporarily disabling tests
- Testing expected exceptions
- Using matchers
- Tagging your BDD tests
- More information
This page is very much a work in progress, but it currently shows a small collection of ScalaTest BDD examples. I’ll keep adding more BDD examples as time goes on. Also, in this article I assume that you are familiar/comfortable with Scala and SBT, and are at least slightly familiar with using ScalaTest.
“What makes a clean test? Three things. Readability, readability, and readability.”
This presentation on property-based testing with ScalaCheck is very good.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 18.3, “How to run tests with SBT and ScalaTest.”
You want to set up an SBT project with ScalaTest, and run the tests with SBT.
Create a new SBT project directory structure as shown in Recipe 18.1, and then add the ScalaTest library dependency to your build.sbt file, as shown here:
From their website:
“ScalaCheck is a library written in Scala and used for automated property-based testing of Scala or Java programs. ScalaCheck was originally inspired by the Haskell library QuickCheck, but has also ventured into its own.”
Imagine that you have a method that requires an
InputStream, and you want to test that method. How can you test it?
In the Scala Cookbook I wrote how your method can accept a
Source instead of a
File to make it easier to test, so I won’t write any more about that right now.
But if you have a method that accepts an
InputStream and you want to be able to test it with a
String, here’s what you can do:
I love this comment from Martin Odersky, from the image shown, which comes from this link:
“Initially, things were too fluid to invest in tests. I simply did not know whether the design would hold up, had to fit a lot of pieces together first. But now is a good time to put these tests in place.”
So often people talk about “Test First Development” that I think they’re insane, or just regurgitating marketing-speak to sound good. There are times when you’re coding things like SARAH where you don’t know how things are going to shake out that “Test First” just doesn’t make sense. If you know what you’re getting into when you’re coding, Test First sounds good, but when you’re exploring, “Oh, this is how SARAH should work”, or, “I thought an FTP server worked like this but it works like that”, Test First doesn’t make sense. (Once you understand the domain, giddyup, test your heart out.)
Include the JUnit library in your project, and use it in the same way you’ve used it in Java projects, with a few minor changes.
Assuming you’re using SBT on your project, include JUnit into the project by adding this dependency line to your build.sbt file:
Problem: You want to use a mock object framework in your ScalaTest tests, such as Mockito.
ScalaTest offers support for the following mock testing frameworks:
Because the support for each framework is similar, let’s take a look at using Mockito.
Before starting, imagine that you have a login web service for your application, and rather than call the real web service during your tests, you just want to mock one up.