Que sera, sera, whatever will be, will be, but first I need more coffee.

Month: December 2015

Winter Solstice

It's only a little thing. We used to go to a friend's house for a Winter Solstice party and one of the ceremonies was to write on a piece of paper things we'd like to get rid of and things we'd like to come in to our lives. Then we'd throw them in a small fire outdoors and make some kind of incantation. Of which I'd forgotten the words.

Those friends have moved away and we have moved away. Those parties are no more. So this year I thought about what I'd like to go and what I'd like to come in: resentment and forgiveness. I need to let go of my resentment that a different friendship was destroyed and that I need to forgive those that destroyed it. The friend who was lost has passed away, so there is no restoring it.

Test Driven Development is driving me nuts

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.
TDD Global Lifecycle

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.

© 2022 Christopher Merle

Theme by Anders NorenUp ↑