Have you written unit tests only later to find they slow you down because your changes cause a lot of test breakage? You think, these tests are not living up to the promises I heard. So you toss the tests and go back to business as usual.
Hey, not so fast. Maybe its not test in general, but your tests or your code. The first project I used TDD on in 1999/2000 we ran into this problem. Some were ready to give up. But I wanted the tests to work and looked for what was wrong. In our excitement we kept copying, pasteing and tweaking the test cases. They were an ugly (in hindsite) mass of duplication. Small changes made for ripple effects through the tests. But I could see, it was our fault.
Someone on Quora asked me “How do you make unit tests less brittle”. Here is a more complete answer based on having written my own bad tests and seen many learners of TDD and unit testing go the wrong direction with their designs and tests.
Creating automated tests can be very difficult, especially when the code has gotten long in the tooth and was not created with automated tests to begin with. Many product development teams don’t invest in automated tests. They think they cannot afford them. They think their product is different and can’t be tested automatically. This thinking is flawed.
Back in the products younger days, manual test was not too time consuming. But slowly that changed. The system grows, the manual test effort grows. Eventually, it seems that no amount of manual test effort finds all the problems.
In this article I show a simple model that illustrates why manual test is unsustainable and that a sustainable software product development effort must include considerable test automation.
I have a few courses that share materials and ideas. I used to use the age-old practice of cut and paste to share the slides. As handy as it is, cut and paste causes trouble. If I’m teaching TDD in C and make a change to a discussion that applies also to C++ or or some other language, I’ve got a problem. I’ll never remember to put the change in the other places where the change is needed. This means that later I find myself in front of a group of C++ programmers about to make a big point, and find that the dramatic conclusion added to the C version I made is not in the current slide deck.
As with code, duplication in presentations is a liability. So I needed to refactor my training materials, and need a practical way to deliver them and provide a PDF handout of the presentation.