What I Learned from Learning about SpecFlow
In my ChessTDD series, I was confronted with the need to create some actual acceptance tests. Historically, I’d generally done this by writing something like a console application that would exercise the system under test. But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix. I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.
But as it turns out, I picked up SpecFlow quickly. Like, really quickly. As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot. What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.
SpecFlow is somewhat intuitive, but not remarkably so. You create these text files, following a certain kind of format, and they’re easy to read. And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read. You tie them to the code files yourself in one of a few different ways. SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops. To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere. IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!
But my reaction to SpecFlow was substantially different. I didn’t see any magic, arcane procedures or peculiarities to remember. Instead, I thought to myself, “oh, I see what they’re doing here. They’re standardizing solutions to two specific problems that I’ve wrestled with over the years: how can you make a test run provide meaningful, readable feedback and how can you efficiently reuse test setup logic?” Next, I thought to myself, “they’re using runtime binding and a static state store.” Finally, I formed passing opinions on whether or not I liked these approaches, and then got down to using the tool to write my tests. All in a day’s work.
But the reason this is all in a day’s work for me is that I have worked for years with the concepts at play. I understand what runtime binding and static state are and what the design tradeoffs are that surround these things. I understand how convention over configuration approaches and behind the scenes magic lay out a nice happy path for newbies, but slaughter then if they wander off of it. I have years of experience writing automated tests and grappling with issues like how to make the output meaningful and readable. I’ve ever written an open source tool to help people achieve this. Learning SpecFlow was easy for me because I’ve spent a decade learning about and experiencing the problems that it solves for its users.
So what did I learn from learning SpecFlow? I learned that there’s tremendous value in really experiencing a problem prior to benefiting from its solution. I struggled with making tests readable and managing setup for a long time, and so I understand SpecFlow intuitively very quickly. I only fully grasped the benefits of IoC containers after feeling the pain of rebuilding and re-deploying an application for a minor or cross-cutting change.
It’s certainly not practical for any developer out there to subject himself or herself to the pain of living without each tool slated for adoption. I don’t recommend that someone starting out writing ASP MVC apps go into the way back machine and start from CGI scripts or classic ASP in order to understand what problems the MVC platform solves for them. But where I do recommend it is in education.
I would love to see a Computer Science/Software Engineering curriculum that started would-be software developers at the beginning and took them through the evolution of problems and solutions in the field. This would have to be executed quite skilfully to prevent glossing over important concepts as well as inundating them with historical minutiae, but I think it could be done. If each entrant into the field had a generalized understanding of the problems and solutions that answered the question, “where are we and how did we get here,” I think the future would hold proportionately more solutions and fewer problems.