I’ve talked about the notion of test description languages quite a bit. A lot of these discussions get into debates about being declarative versus imperative, or focusing on intent rather than implementation. All good things to consider. But such “versus” … Continue reading
Category Archives: BDD
Awhile back I wrote up some context around the question of Is Cucumber Truly Misunderstood?. There is a wider concept here that makes these tools quite applicable in the modern testing context, so I want to cover that here.
The whole notion of BDD is something I’ve talked about in a series of posts. I recently did an exercise with a group of business users, testers, and developers. We used a contrived example but the example was certainly a … Continue reading
I’ve talked about “being lucid” and using description languages before. I have a whole category here devoted to TDL (Test Description Language) and I’ve worked to present examples that are not your standard “shopping cart”. In this post, I’ll cover … Continue reading
Previously I talked about the testing craft and abstraction and here I’ll expand on those thoughts a bit more.
Previously I had talked about the craft of testing, focusing on the balance between the creativity of an artist and the methodology of a scientist. In both cases, however, the focus is on communication. To that end, it’s imperative we … Continue reading
Many people feel that tools like Cucumber are a waste of time. But are they? Let’s talk about that.
I’m tired of hearing how “Cucumber is misunderstood.” If that’s the case then it’s terribly ironic that a tool that is supposedly all about revealing intent did such a bad job of doing this for itself such that it’s become … Continue reading
If you plan on using a BDD tool (like Cucumber, SpecFlow, Behat, etc) you are going to want to have some guidelines for how and to what extent you allow parameterized and conditionalized phrases. This is an area that I’ve … Continue reading
There are many references out there that discuss Gherkin, which is a structuring element for your test description language (TDL). So what I’ll be offering here is really nothing new. This post is simply a relatively concise look at the … Continue reading
Regarding my post on Seeking Requirements in TDL, a comment was made regarding the question of whether or not I was focusing on the conditions as part of the scenario and whether or not this tied into how I view … Continue reading
Regarding my previous post on this subject, a tester I work with asked me a great question regarding the readability of the TDL and the ability to discern the actual requirements from it. This post is essentially what my answer … Continue reading
The goal of a Test Description Language (TDL) is to put a little structure and a little rigor around effective test writing, where “effective test writing” means tests that communicate intent (which correspond to your scenario title) and describe behavior … Continue reading
A TDL (Test Description Language) is a constructed language that we use to describe, and thus specify, our requirements as tests. Or our tests as requirements, if you prefer. This is what allows testing to be a design activity. What … Continue reading