Chess TDD 30: Starting To Be Idiomatic With SpecFlow
This episode went so poorly, I thought briefly about scrapping it and starting from scratch… but that would not be true to the premise I established at the outset where I’d do this unedited, flubs and all. Having finished with the AsciiBoardBuilder, it was time to start putting Darren Cauthon’s ideas into play. You can read up on that here. I sized up what he had done and, in spite of knowing very little about SpecFlow, decided that I only needed certain parts of it for my purposes. This turned out to be a mistake as something that I thought he had just added for illustrative/cosmetic purposes was decidedly non-cosmetic, and it took me a lot of floundering to figure that out. Now, that’s not uncommon for me, per se — I’m a “figure it out by breaking it” sort of person, but it’s not exactly the stuff of scintillating videos.
Here’s what I accomplish in this clip:
- Got the first idiomatic SpecFlow test written in the new feature. Barely. And ugly.
Here are some lessons to take away:
- When using someone else’s example as a template for learning something you don’t yet know, don’t jump the gun and start tweaking and changing things before you get the example working. Do as I say, not as I do.
- No matter how long you’ve been doing this, you’ll still make off by one errors and get array bounds arithmetic wrong when it’s complicated. Improve the odds in your favor by using TDD or, by some other mechanism that you come up with, if applicable.
- When you find yourself writing a good bit of logic in test code (meaning, you’re writing a lot of code that you aren’t test-driving), ask yourself whether you could move the logic to production or find some other way to tease it out with TDD. You can see by my floundering here that you become decidedly less productive when you’re writing a lot of code and just hoping for the best.
- Using NCrunch, it’s pretty easy to run quick experiments to help with my debugging. One such example was to start hard-coding the row/column indices to see for which ones exceptions were actually generated.
- Similarly, putting a temporary precondition assert at the top of a test method to check your assumptions can also be a big help. This is what started me down the path of realizing my mistake with the table’s header. I finally sanity-checked my assumption that the table had 8 rows to find that it really only had 7.