Tech — Work — Ramblings

by Mike Kalvas

202609091009 The Devil's Advocate method of testing

The Devil's Advocate version of testing and software engineering is a form of test-driven design where the implementation is the most direct, simple, and bad-faith implementation as possible.1 For instance, if we're making a sum function we might have code tests like this

it('sums 1 + 1 to 2', () => {
    expect(sum(1, 1)).toBe(2);
});

Using the devil's advocate method, your implementation would look like this

const sum = () => {
    return 2;
}

You can see that this is obviously not a general solution that satisfies the mathematical concept of summation, but it does pass all the tests. Why would we do this then?

The purpose of the devil's advocate method is force your tests to be the set of assertions, scenarios, inputs, etc. that are actually required to guarantee that an implementation is sufficiently correct for your use case. We would continue extending the tests until the implementation was forced to be just generic enough to satisfy all the behaviors that we would expect it to. To see just how far this can be taken and as an exercise to the reader, I challenge you to find tests that force a general summation implementation.

As your tests get more specific, the code gets more generic.2


  1. Seemann, M. (2021). Code that fits in your head: Heuristics for software engineering (First edition). Addison-Wesley. ↩

  2. Martin, R. (2013, May 27). The Transormation Priority Premise [Blog]. The Clean Code Blog. https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html ↩