I was talking with Nathan Ladd, one of the Eventide co-creators, the other day. He said something that really stuck with me.
When you have a bug, an error, really any condition where your system isn’t running the way you want it to, first elevate your level of understanding. Then the solution becomes obvious. If you don’t have an obvious solution, you don’t understand the problem well enough yet.
This made me think about Test-driven Development and why I believe it’s superior to a test after-the-fact strategy.
When you’re doing TDD, you don’t just run the tests after you write the code that’s supposed to make your failing tests pass. You state to yourself, if you find yourself in the unfortunate case of working alone, or to your team if you’re in an ensemble what you expect the code to do.
I often run the test I’m working on as I type each line of code needed to get the test to pass and see the errors I’m getting change as the code comes into focus. With each run, I predict not just that there will be an error but what the specific error is. I do this right up until the test passes.
This constant thinking through of what the code is doing drills into my head how it’s supposed to operate. I don’t see how writing tests after-the-fact could do that.
