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.By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.
I find SpecFlow to be best paired with a UI automation framework like Selenium or WaitN etc, then the specs are acceptance files.
In theory specs could be written by business analysts or even business users themselves. Somewhat improbable that it would truly occur but at the minimum you can hand the specs off to a BA and they pick them apart. Because specs should be written in business language, never in devspeak.
Definitely a big fan of having a living, executable spec in plain language. With the ChessTDD series I’m doing, I have no designs on a GUI, so I don’t know that I could easily run the experiment of pairing it up with Selenium, but who knows. Maybe I’ll finish the current trajectory and want to keep going with the experiment.
If it’s bot vs bot, the test runner is a valid “gui” in and of itself.
https://gist.github.com/darrencauthon/caec988d7c928f4ad602 All due respect to dotnetchris… I know there are many opinions about how to use these sorts of tools. But in my opinion, you bind SpecFlow and start running tests through a UI, you’re doomed. It will work for a while, it will seem just fine… and then the tests will become more fragile and more complicated. And fragile and complicated tests destroy the confidence of the team in the testing. Also, Gherkin is not “business language.” Nobody talks in Given/When/Then. Gherkin is more readable than Gherkin, no doubt, but I’d be very wary of every letting anybody see… Read more »
Added my comment to the gist, and thanks for laying all of this out.
As an aside, I’ve dealt with some BA/PM types that don’t struggle with Gherkin. It’s a little awkward compared to natural language, but I think it’s definitely grok-able for them. (I’m not really commenting on a process flow, per se, just that I think they could understand the spec and what passing meant)
I’ve had some success with Gherkin and certain people, too. I remember the first time there were questions about how this one module operated, so I printed out my SpecFlow feature and passed it along. They were blown away that the specs were so descriptive and they could “follow along.” I tried it with a different manager on a different team, and she thought I was crazy. I was going to pass it off as a personality issue, but something happened with the positive Gherkin managers: I had two directions I could go. I could write a scenario like this:… Read more »
Take a look at TickSpec on codeplex its basically SpecFlow without the code generation layer.
Bookmarked. This might be the perfect excuse for me to do a foray into F# that isn’t just playing around for the sake of it.