- Consulting / Coaching
- Jeff’s Blog
Some articles seem slightly embarrassing to me after I see them published. I thought this might be one, but I think the point should be well-taken: we’re way too invested in dogmatic process trappings. This blog post for Ranorex tells the story of a day in a life where we don’t talk about a process, we just live it, with the singular goal of delivering high-quality software frequently.
Breaking Through the Barriers to BDD (14-Jun-2018)
I think I’m getting a better feel for the interview-style webinar, not having done much of them in the past (this is my… um… second one). This webinar is a discussion around things like organizational resistance to BDD, and touches on the core notions for what can make BDD succeed in your organization.
The ABCs of Acceptance Test Design (7-Jun-2018)
In this blog post for Ranorex, I present seven design principles for the tests you’ll craft as part of practicing behavior-driven development (BDD) or acceptance test-driven development (ATDD). Stick to these principles and you’ll create a body of tests that returns many benefits while allowing you to keep your sanity.
A number of good questions about BDD arose from the Gurock webinar “BDD Testing Skills,” delivered on April 13. I felt like answering them all, though I did so rather hastily. You’ll find the questions-and-answers here. (15-Apr-2018)
Simon Knight interviewed me for the Gurock webinar “BDD Testing Skills,” delivered on April 13.
During this session we talked about:
Succeeding With Test-Driven Development at a Distributed Start-up (17-Jan-2018)
In this blog post for Gurock’s blog, I talk about my experiences doing test-driven development (TDD) at a small startup: Where did we succeed, where did we fail, and what would I change?
Clarifying Scope with Scenarios in Behavior-Driven Development? (19-Jan-2018)
In this article written for Gurock’s blog, I talk about the values of negotiating around scenarios when doing behavior-driven development (BDD). Rather than delve deep into the narratives (given-when-thens), this focus will help when it comes to negotiating the scope of a given story.
Should We Automate All of Our Feature Scenarios? (8-Feb-2018)
This post for Ranorex’s blog talks about how behavior-driven development (BDD) can help us come to consensus. I share a story about a customer who found value in BDD, even though we were unable to automate their “specs by example.”
Your business doesn’t want to hear about how you “delivered stories.”
The business wants you to deliver value, in the form of what they most likely refer to as features.
A story should trigger a conversation around a feature request. Your software product doesn’t contain stories, it contains features that help users accomplish goals.
Wikipedia describes a user story as “one or more sentences” that capture a user’s needs. Those sentences represent a brief description or summary based on the planning and preparation so far, and they are reminders of the conversation that you must continue to have around the feature you will build. The sentences are not the feature. They aren’t even the full story, in most cases, as it often takes the requester several more oral sentences or even paragraphs to say what they really want.
If you think about stories as a simplified form of a requirements document (“a couple sentences”), you’re constraining agile to be a small tweak to how you did things before, with a trendier name. That diminishes the most important aspect of how agile can help you deliver software successfully: Through continual collaboration and oral communication. Without understanding of the importance of collaboration, stories end up being another waterfall-like hand-off document.
On another front: Too many teams waste time over the wording of a story. It’s a discussion point, not an artifact. The “standard” story template should help you clarify feature requests by asking you to think about who needs them and why. But otherwise spending time on precise word-smithing of a story writeup misses the point. You’re going to discuss it, and you can iron out any ambiguities as you do.
Stories provide only minimal value as an artifact. The ensuing discussion is where the details come out. Unfortunately, most of us can’t fully recall details from a conversation a half year prior, or even a half month prior. Granted, the details end up embodied in the software, but source code more often than not does a poor job of expressing such details concisely and simply. Even programmers must sometimes spend hours to determine just what the code does for the smallest of features.
We need a better artifact than the few sentences that represent a story. Many successful teams have found that the best way to capture system behaviors is in the form of acceptance tests, best derived by use of acceptance test-driven development (ATDD) or BDD. The acceptance tests supplant the nebulous conversation with real meat. A test’s name describes the goal it accomplishes, and its narrative provides an example that quickly relates the details of system behavior. The set of test names describes the complete set of designed system behaviors. The tests capture the important detail behind the discussion triggered by the story.
A story is not a feature, and it should always trigger a conversation.
My initial reaction a few years ago to BDD implementations in Java was less than stellar. Since then, I revisited them a couple times, and now I’m digging into them again. They’re still around, so someone must be getting value out of them. I certainly have gotten some mileage around naming and organizing my tests in a more BDD fashion.
Right now, I’m being lazy, and haven’t done diligent research. But my initial internet searches suggest that there are a handful of tools, none of them the de facto standard. I remember my doctor once saying, “We have about a hundred ways to treat this [a plantar wart]. Usually when there are so many ways, it means we don’t know what we’re doing.”
I started looking at one framework in more depth, and coded some straightforward examples. Didn’t seem so bad, until I looked to code a more involved assertion. Here’s one (contrived but simple) example:
Ensure.that(name, and(contains("Langr"), startsWith("J")));
One of the core principles of BDD is “getting the words right.” I think this example demonstrates that sometimes we try too hard, and perhaps this construct isn’t a great idea for Java. The “classic” approach is easily more expressive:
assertTrue(name.contains("Langr") && name.startsWith("J"));
assertFirstInitialAndLastName(name, "J", "Langr");
I suppose my complaint could be tempered with the fact that these kinds of compound assertions don’t occur so frequently.
Yes, sure, the failure messages are better. That’s not significant to me, given that I don’t drive my development off of failure messages. Sure, all tests fail at least once, but I usually know why they’re failing the first time, so I don’t need that message initially. Later, when they fail for unknown reasons, more information might be useful (sometimes it is, not always), but if I need that, I just enhance the assertion I already have and rerun the tests. No big deal.
Writing custom “matchers” is also an example in ugliness, given the limitations of Java. (I need to speed up my move to Groovy or Ruby, so I can stop whining about Java so much…)
I won’t give up on the Java BDD tools completely, but I’m not much happier now than I was three or so years ago.