Photo by Karine Avetisyan on Unsplash

In my previous article about the effective usage of test doubles, I described how mocks and stubs can be introduced to define contracts between internal components of a closed system (e.g. a microservice). This post will show you how to extend this approach to external contracts and how to integrate consumer-driven contracts in the development flow with test doubles.

What is a contract?

Wikipedia describes a contract as “a legally binding document between at least two parties that defines and governs the rights and duties of the parties to an agreement”. Let’s translate this definition into the realm of software components:


Photo by Paul Teysen on Unsplash

In this article, I’ll show you how to apply functional programming techniques to achieve greater abstraction and flexibility in your code. We’ll refactor together a rigid code towards a more generic solution by introducing folding (or reduce), higher-order functions, and combining values in an abstract way (with a fancy name of monoid). Let’s jump straight to the problem statement and the Scala code!

Problem

We are developing a supermarket point-of-sale. The first requirements and examples are simple:

Starting point


Photo by Etienne Boulanger on Unsplash

This is the second (and the last) part of my longer article about applying effectively test doubles. In part 1 I presented tips on tactical mock/stub usage. I assumed that you were already using mock objects, I gave hints about how to squeeze the most out of them and avoid increasing test complexity. In this part, I’ll talk about when and how to introduce mock objects in your tests. The following advice doesn’t require you to follow test-driven development; they apply even if you write the tests after implementing the production code (although I recommend you strongly the former approach).

Introduce test doubles for boundaries to keep outside of your tests


Photo by Austin Distel on Unsplash

Twenty years ago, Endo-Testing: Unit Testing with Mock Objects, the first paper on mock objects was published. Its authors described the usage of real object replacements to improve both the production and the test code. They named Mock Objects them after Mock Turtle, a creature from Alice in Wonderland that believed it was once a real turtle. Just as the story about Alice — surreal, psychedelic, and apparently nonsensical — mock objects are still not fully understood by the software community.

In part 1, I’m going to share some tactical tips about the efficient and effective usage of mock objects…


By Ssolbergj — Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=2992630

September, 52 BC, Alesia, Gaul

Julius Caesar was waging wars in Gaul for six long years. He thought he had conquered Gallia for the glory of Rome, but in 52 BC a young, ambitious, and charismatic chieftain, Vercingetorix, managed to unify the Gallic tribes and revolted against Romans. Caesar pursued Vercingetorix and his fellow soldiers. Vercingetorix retreated to Alesia[1], a large fortified settlement, together with his ca. 80.000 fellowmen.

Caesar decided to siege Alesia and to starve out the defenders. He encircled Alesia with 16 km long fortifications to protect his troops from sorties and enforce the blockade. Vercingetorix called for support from other Gallic…


Photo by Toa Heftiba on Unsplash

This time I’ll talk about the use and abuse of test helper methods. But first, let’s start (again) with a short description of why we are writing tests and what is a test for?

A test sends stimuli to the test subject and examines the response. In a more plain language, the test prepares some input data, then it executes a method on a class or a function in a module and finally compares the output values with the expected ones. It is the very basic goal of the test. You can reach it even with the spaghetti test code…


Photo by Coffee Geek on Unsplash

A good test provides evidence of how the System Under Test (SUT) transforms inputs into outputs. We set up a test fixture, execute the SUT, and finally, we verify the results (structure known as Setup-Execute-Verify or Arrange-Act-Assert). In this article, I’ll focus on how to verify the outcome of the SUT and mock interactions in a simple and easy way.

Procedural State Verification

If there is a simple and easy way — what are the complex verification techniques? The most common one I encounter in tests is the so-called Procedural State Verification. The test compares each and every property of an object with…


Photo by Glen Carrie on Unsplash

When people hear the word fixture in the context of tests, they may imagine a huge dataset in the database or REST service mocks. The test fixture is a broader concept. And usually has a much smaller scope than you would expect.

A test fixture is defined as everything you need to execute the System Under Test (SUT, it can be an object method, standalone function, or a microservice API). And you will require:

Marcin Gryszko

Enduring software engineer and long-distance cyclist

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store