Chess TDD 23: Yak-Shaving with SpecFlow
I’m writing out this paragraph describing what I’m planning to do before recording myself doing anything. This post has been a while in coming because I’ve waffled between whether I should just hand write acceptance/end-to-end tests (what I generally do) or whether I should force you to watch me fumble with a new tool. I’ve opted for the latter, though, if it gets counter-productive, I may scrap that route and go back to what I was doing. But, hopefully this goes well.
Having fleshed out a good bit of the domain model for my Chess move calculator implementation, the plan is to start throwing some actual chess scenarios at it in the form of acceptance tests. The purpose of doing this now is two-fold: (1) drive out additional issues that I may not be hitting with my comparably straightforward unit test cases and (2) start proving in English that this thing works. So, here goes.
Here’s what I accomplish in this clip:
- Installed SpecFlow plugin to Visual Studio
- Set SpecFlow up for the ChessTDD project.
- Wrote a simple acceptance test.
Here are some lessons to take away:
- There is a camp that favor ATDD (acceptance test driven development) or “outside-in TDD” and another that prefers “traditional” or “inside-out TDD.” I’m not really in either, but you might find that you have a preference. Both approaches are worth understanding.
- What I’m doing right now, for the moment, is not test driven development. I’m retrofitting acceptance tests to bolster my coverage and see if the more micro-work I’ve done stands up to real world usage.
- If you want to see how someone that doesn’t know SpecFlow gets it set up, this is the video for you.
- If you’ve been tinkering with a test for a while and the test was green the whole time, how do you know you’re done? With your assert in place as you think it should look, modify it quickly to something that should fail and confirm that it does. The idea here is to make sure that your modifications to the test have actually had an effect.