1. 8
  1. 6

    I think this is roughly correct, and although I don’t feel at all enlightened, I think I’ve hit the ‘pragmatic’ stage. But like everything, the approach to testing is very domain dependent.

    I’ve worked on public facing authentication systems that handled hundreds of thousands of requests per day (millions in peak times). We tested it to an insane degree - unit test overage of about 90%, integration tests that covered every possible permutation of data provided to every service endpoint, plus automated UI flow testing that covered about 90% of the possible paths a user could take.

    It was amazing, and we had zero bugs in production. But we spent about 80% of our time writing and maintaining the test suite, and 20% adding new functionality.

    Currently I’m working on a (complex) CRUD system. We mostly only unit test the more complicated parts and rely on (not all that rigorous) integration, automated UI and manual tests to pick up issues. It’s not public facing, so if I a bug slips through it’s not the end of the world. We probably spend about 20% of our time on testing.

    Both approaches were pragmatic, given the domain.

    1. 4

      Managing a codebase requires an entirely different mindset from the one needed to control a machine. It requires knowing how to deal with the unpredictable flux of a complex, wild organism.

      This sounds like defeat to me. The author feels out of control. Nobody knows what the code actually does.

      1. 2

        I think you’re right, but I also think that that attitude is what most people have about their codebases. Unit testing can really help to get the entire thing under control and it provides a sort of functional documentation (that won’t get outdated!) to help others get up to speed.

        1. 2

          It’s particularly easy to have that attitude about a codebase that you are new to, where most of the existing work was done by people you don’t necessarily know and involves concerns you don’t necessarily understand because you weren’t there at the time.

      2. 3

        What do system programmers (non-managers) think about TDD? Functional style programming, TDD, and unit testing all go together. Often web and app people are the cheerleaders of all three. The more functional the code, the less complicated it is to mock side-effects when doing TDD. System-programming tends to be more procedural. And often shared data is mutated between hungry processes to reduce memory overhead and latency. How do you TDD (write unit tests first, always) something like that with so many side-effects and corner-cases? The mocking cost must be really high and you still can’t catch everything, no?

        1. 2

          I do systems programming and use TDD 99% of the time with no issue.

          1. 1

            Does TDD push you to minimize side-effects in as many methods as possible? And are you doing data-intensive stuff with mutexes, locks, and semaphores?

            1. 2

              Does TDD push you to minimize side-effects in as many methods as possible

              I minimise side-effects as a rule anyway. Any technique I’d use would result in hardly any side-effects.

              with mutexes, locks, and semaphores

              Why would I want to write code that explicitly locks mutexes? To me that’s like writing assembly on purpose.