Let’s get the excuses out of the way: busy, more work coming in, vacation, yada-yada. Sorry for the delay since last time. This episode is a short one just to get back on track. I haven’t been writing much code lately in general, and I was already stumbling blindly through SpecFlow adpotion, so this was kind of just to get my sea legs back. I wanted to get more than one acceptance test going and start to get a feel for how to divide the acceptance testing effort up among “features” going forward.
Here’s what I accomplish in this clip:
- Cleaned up the dead code oops from last time.
- Defined an actual feature file for spec flow, with four real acceptance tests.
Here are some lessons to take away:
- I don’t really know how Specflow works very well, so that floundering around after pasting in the same text seemed to fix the problem is my way of avoiding programming by coincidence.
- No matter what you’re doing (unit tests, production code, or, in this case, acceptance tests) you should always strive to keep your code as clean and conformant to the SRP as you can.
- When you don’t know a tool, go extra slowly with things like rename operations and whatnot. I’m referring to me changing the name of the spec flow files. It’s easy to get off the rails when you don’t know what’s going on, so make sure you’re building and your tests are green frequently.