ChessTDD 36: Acceptance Tests for Queen Movement
This episode went smoothly until I discovered a bug. Philosophically, I suppose this is the natural state of software development. For my purposes here, though, hunting down the bug caused the episode to balloon to 26 minutes, so I’m going to try a new thing so as to keep the videos a reasonable length of time. I’m splitting it into 2 videos: parts A and B. Please let me know if this approach is preferable to sometimes having long videos or not; if you leave feedback, I’ll more likely do it the way you prefer, since I’m just trying to go with what people like.
What I accomplish in these clips:
- Created a couple of code snippets in CodeRush to get rid of the hand typing in the specflow scenarios.
- Wrote acceptance tests for the queen’s movement.
- Squashed a subtle bug (or at least half of one).
Here are some lessons to take away:
- Projects go better when there are more eyeballs on them. Run things you’re doing by other people and see if they have suggestions that might help. They may think of things that never would have occurred to you and might later seem obvious.
- Whenever you make mistakes copying and pasting, it’s a crapshoot whether fixing them takes more time than you would have spent hand-typing or not. In my experience, most of the time you don’t come out on the winning end, and wholesale copy-paste obscures your understanding. This is why I try to avoid the practice.
- What I find is that unit tests should be very directed and specific about system behaviors. But acceptance tests let you put on your exploratory testing hat, dreaming up scenarios in which users might use this thing that could potentially break it. For you unit testing newbies, fight the urge to write unit tests with lots of assertions that cover a lot of ground. You can express that in your acceptance tests.
- Once again, don’t do low-hanging fruit refactorings (e.g. deleting dead code) when you have red tests. It might seem like it’s not a problem, but it will come back to haunt you at some point.
- Another example in this episode of finding a bug with a failing acceptance test, and drilling in to get closer by writing failing unit tests. This is an excellent and helpful practice.
- TDD facilitates Eureka moments where you try something you think might work and you see all of your tests go green. However, just like trying something in your code and seeing the application magically behave correctly next time you run it, it’s important to cement your understanding of why it worked. Don’t program by coincidence, even if you have a green test suite backing you. Keep writing tests and/or reasoning about the code until you’re sure you understand what’s happening. (Writing tests provides an excellent way to prove your understanding to yourself).