Chris James

Developer and other things

Property-based testing in real life

Published on 27 August 2016

Most property-based test examples you see on the web are contrived scenarios and people can be dismissive of them, claiming that they aren't actually practical. This post will have a simple example applied to one of my projects which will hopefully illustrate their value.

This is a follow up to Property-based testing in Go and if you're not familiar with these kind of tests I suggest you read that first, it's a quick read.

Although the examples are in Go there are QuickCheck frameworks for most mainstream programming languages and the concepts described here will still apply.

This post will:

  • Briefly explain the domain
  • Describe writing a real world property-based test
  • Summarise my conclusions

mockingjay server

It's important to have a good knowledge of the domain when writing property-based-tests, the following is an overview of the domain we will be testing.

mockingjay-server (MJ) is an application which is a lightweight HTTP server driven from configuration.

MJ has two "modes":

Server mode

Serves responses matched to requests that you define.

Compatibility or CDC mode

Take that same config, executing each request against a given URL and checking the response is compatible with the response in configuration. This is known as a consumer-driven contract (CDC).


When writing integration tests against a HTTP service you will usually make a fake server (or some kind of stub around HTTP) to write tests against. You will then make your tests pass and be happy right?


  • Fakes dont always correspond with the real behaviour
  • Fakes might behave correctly at first, but if the downstream service changes the fake could be wrong

In both of these situations your build would be green but your software is broken.

mockingjay allows you to make a server and easily verify that it is equivalent to what you're testing against. You can then distribute this configuration as a CDC for the maintainer of the downstream service, so they dont accidentally break the service for your use case. The wiki goes into this more.

There is an inherent coupling between HTTP integration tests and consumer driven contracts. MJ leverages this in a single config.

A property of mockingjay

To write a property-based test we need to identify a property to throw lots of auto-generated data at, to make sure the property holds true.

A property of MJ is:

MJ should always be compatible with itself

Here's my thinking:

  • Given Config A
  • When You start an MJ server with config A
  • And you run a CDC check using config A with the URL of the running MJ server
  • Then the CDC check should pass

If it doesn't it either means there is a flaw in the CDC algorithm or in the way the server is behaving.

I have lots of example based tests for this but if I invest time writing a property-based test I can be really confident MJ is working.

Create a generator

For all but the basic types you will need to create a Generate method for the input type in your test. This will allow the quickcheck package to create thousands of different data points to check the property against.

I made a simple one to start with and other HTTP things like headers, forms, etc can be added later.

FakeEndpoint is a representation of the config from earlier.

Test the property

  • Write a function which takes the randomly generated endpoint
  • Start an MJ server using that endpoint
  • Take the same config and run the CDC against the server
  • If there are any errors then the check fails

When I ran the test I was pleasantly surprised in that the CDC check failed.

Couldn't reach real server: Post 303 response missing Location header

This means the CDC tried to POST to the configured URL and Go's HTTP client returned an error.

This is quite exciting, I haven't seen MJ configured with any 3xx response codes so this points to some naivety in my code.

HTTP 303 is "See other" which relies on a location header to get redirected to another resource.

Investigating Go's HTTP client

Before writing any code for this I wanted to have a look at the Go source of http.Client to see exactly how it works.

By following a few of the function calls we can see if it's a POST or a PUT and the status is a HTTP Found 302 or See Other 303 then it will expect a location header that it can parse with req.URL.Parse.

I will have to add some additional validation to the configuration so that these rules can be respected or make Go's HTTP client not follow redirects.


The costs of writing property-based tests are low (this took me about 10 minutes) and can help give you a lot of confidence in your code (or not!).

What's great is that even on a very simple generator implementation the tests uncovered some bugs.

This style of testing can:

  • Improve knowledge of the problem domain
  • Find bugs you wouldn't have thought of otherwise

These things prove that property-based tests can improve the quality of your software.


Other examples of this style of testing in the real world:

QuickChecking Riak

In this talk John Hughes shows us how QuickCheck helped us to model Riak’s behaviour, improving understanding and revealing the occasional bug.

John Hughes - Testing the hard stuff and staying sane

Taking 3k lines of specification to create 20 lines of QuickCheck to test 1 million lines of code from 6 different vendors. Some real war stories in this video.


Published on 25 March 2016

Magic is often used to describe confusing code. Often we cannot explain how something works so magic seems like an apt description.

The problem with magic is that it’s an entirely subjective term which can be used as a very annoying stick to hit useful abstractions.

An anecdote

A while ago I wrote something along the lines of this in Scala.

val transformedCollection = collection map transformer

For those not familiar with the map construct, this will run the transformer function on each item in the collection, returning a new collection of transformed items.

Another nameless programmer chastised me

"I like to be pragmatic"

(Who exactly doesn’t like to be pragmatic?)

"This is magic, why not just write a for-loop, it’s clearer"

Apart from the pragmatic comment it’s actually a reasonable thing to say, if you don’t understand how something works then it’s magical!

Understand the magic

Just because something seems magical doesn’t mean it’s wrong. The problem with the term is it’s often lazily used when someone doesn’t understand an abstraction, or worse - doesn’t want to understand.

So what is magic?

For me I get the feeling of dark arts surrounding me when there is a lack of explicitness. Generally stuff changing “underneath” me based on some kind of state of the system. It often feels like the code is working by accident rather than deliberately.

Anti-patterns like global imports and setter-based DI makes the system feel magical in a very ugly way.

Choose your spells

From time to time all of us look at some code and throw our hands up in the air when we don’t initially understand something. Rather than unsheathing our anti-magic sticks make an attempt to understand it first.

There’s nothing more annoying than someone describing your code as magic when you feel you put some effort into a useful abstraction. So try to be considerate when faced with unfamiliar constructs.

That being said it is important for programmers to share their knowledge when introducing something new. Be sure to explain your sleight of hand at code review and use abstractions tastefully and keep intent clear at all times.


Don't lazily conflate the unfamiliar with magic. It's short-sighted and annoying.