I’m working my way through Test Driven Development With Python and I don’t quite grok it yet. It feels like I’m missing part of the puzzle. Granted I’m only in the early stages of the book, but still. It feels like how the Underpants Gnomes operate:
Step 1: Collect underpants.
Step 2: ???
Step 3: Profit!
As a developer I want to be more rigorous in my development process. Right now I’m a bit of a cowboy coder (no, not in the cyberpunk cowboy hacker sense). In the sense I play it by ear and that my process changes with little formal documentation. My source control is making copies and storing them on my computer or having two setups. I do keep notes but they aren’t in one central repository nor labeled for what project they belong to. Most of my documentation is the email conversation I have with my clients.
The TDD process is
Step 1: Write a test that fails
Step 2: Write shell code that makes the test pass barely
Step 3: Rewrite the code so it actually functions and passes the test.
It seems backwards. You write a test first then write the code that will pass it. The step I’m missing is the requirements. Just because you write it so that it passes, it doesn’t mean the code will actually do what you or the client wants it to do. And then in the back of my mind I’m conflating it with today’s teaching methods in grade school. Kids aren’t being taught to learn. They are being taught to pass the test which means they aren’t really learning anything.
So I guess that is my big fear that I’m not learning anything. Just how to be a better test writer.
Don’t get me wrong. Testing code is essential but you can’t think of all the use cases. People will try to use software in ways that it was not intended. You can write code that will test functionality and you can write code that will test the code, unit tests. Then there’s refactoring, rewriting the code so that it’s cleaner and easier to understand. Why don’t you write the code clearly in the first place? As with any writing revision is important even in programming.
TDD is only one part of the development to deployment cycle. It looks useful and I’ll keep plowing through the book and hopefully it will begin to make sense.