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.
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:
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!
We are developing a supermarket point-of-sale. The first requirements and examples are simple:
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).
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.
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, 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…
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…
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.
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…
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:
Enduring software engineer and long-distance cyclist