Property-based testing in real life

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.

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.

-name:My very important integration pointrequest:uri:/hellomethod:POSTbody:Chrisresponse:code:200body:'{"message":"hello,Chris"}'headers:content-type:application/json

Server 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).

Why?

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?

But:

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.

When the YAML file is read, each endpoint is read into a type called FakeEndpoint

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

Test the property

Write a function which will act as our assertion. It will takes the randomly generated FakeEndpoints from the quick package and check our property holds true.

Start an MJ server using the random endpoint

Take the same config and run the CDC against the server

If there are any errors then the check fails

funcTestItIsAlwaysCompatibleWithItself(t*testing.T){compatabilityChecker:=NewCompatabilityChecker(noopLogger,httpTimeout)assertion:=func(endpointFakeEndpoint)bool{// Start an MJ server with the random configurationmjSvr:=NewServer([]FakeEndpoint{endpoint},false,ioutil.Discard)svr:=httptest.NewServer(http.HandlerFunc(mjSvr.ServeHTTP))defersvr.Close()// Run CDC against "itself". An MJ server should always be compatible with itself.errors:=compatabilityChecker.check(&endpoint,svr.URL)iflen(errors)>0{t.Log("It wasn't compatible with itself")for_,err:=rangeerrors{t.Log(err)}}returnlen(errors)==0}config:=quick.Config{MaxCount:1000,}iferr:=quick.Check(assertion,&config);err!=nil{t.Error(err)}}

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

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.

Conclusions

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. So find out how to do these kind of tests in your favourite programming language and give it a go, you might learn something.