1. 13
  1. 7

    I think the 3 plates method is actually a good illustration of how unit testing fails: after the red and green plate are lapped against each other, neither is flat – they simply agree with each other in some unknown way. It takes the introduction of the third plate that interacts with both of the other plates independently to bring all 3 plates to absolute flatness.

    In the same way, a test suite and a tested codebase can easily move in lockstep, being iteratively adjusted to each other, while still encoding some bug – like an unknown type of input that both triggers a bug in the codebase and isn’t tested for in the test suite.

    1. 4

      First some terminology….

      The third plate is the production code that uses the tested code.

      You should always have precondition checks just inside your code under test.

      This acts as a test on the test, when you link to the production code, this acts as a test on the code that invokes the unit under test.

      1. 1

        Would readelf and objdump provide a better analogy with the 3 plates method? (With compiled object files providing the third plate against elfutils and libbfd views of object file formats.)

        https://stackoverflow.com/questions/8979664/readelf-vs-objdump-why-are-both-needed

        The analogy is still imperfect, since readelf doesn’t interface with libbfd directly.

      2. 2

        I think we don’t test our tests because they’re not treated as “artifacts” in the same way our production code is. It’s also why we don’t benchmark or log them, either. As tests get more complex, say with fuzzing or E2E tests, then treating it as an artifact makes more sense. I play with this idea a bit here.