ChessTDD 38: Bishop Tests and Being Wrong about Being Wrong
For this episode, I did something a bit different. I actually recorded the coding for this and then two more episodes on its heels. If you’re following along on github, you’d notice that I’ve checked in code for episode 40, though I still need to do the audio for those next two episodes. In this particular episode, I get off to a nice start with testing for bishop and then get a bit derailed. Luckily (spoiler alert), I get it straightened out in next episode. And, for all 3 of these, I successfully kept to right around 20 minutes.
What I accomplish in these clips:
- Implement part of the acceptance tests for bishop.
Here are some lessons to take away:
- I find a lot of benefit in stripping everything but what I need in default templates I’m provided (e.g. the spec flow feature file, an web.config file, etc). I prefer to be as deliberate as possible about everything that goes into the software work product.
- No matter what you’re doing, if you do it brainlessly, it won’t go well. I avoided copy and paste to avoid brainless mistakes, and just wound up brainlessly typing in the wrong thing by hand.
- TDD lets you poke at and test the code to see if you can get to green (or red) without fully understanding what you’re doing, but if you do this, make absolutely sure you spend time immediately afterward writing tests or reasoning about the code so that you do understand it.
- You almost certainly won’t stop yourself from making stupid mistakes, but you can develop techniques for discovering them more quickly and reducing their impact scope.