The article, which is un-surprising good in the technical aspect, claimed that the testing framework is able to process your testing scenario in plain text, from the user’s perspective. Without having looked at Cucumber: This is wrong.

“But wait,” you say, “you haven’t looked at Cucumber.” True. However, I bet you dollars to donoughts, that, just as with RSpec, Shoulda, and any other testing frame work, you’ll have to learn a vocabulary to express your thoughts, so that the tool understands what you want. Just because computers can’t do natural language processing. Yet, anyway.

Let’s stop misleading ourselves, in implying that “plain text” means “natural and intuitive”. It isn’t. If I wouldn’t know that Cucumber is doing Behavior Driven Development, I’d have no idea what “Given a…” meant in this context.

For us humans, text needs context, and that has to be provided somehow. This is even worse with computers: We can derive context from content, computers are too stupid to do that. Accordingly, Cucumber needs you to write the test parser (judging by the most curious look I gave it. It’s probably just fine tuning the actual testing and mock ups). Using Regular Expressions, too (just to add insult to injury )

How about we call “plain text” and similar things “understandable”, instead? After all, while these tools don’t live up to what is implied, they are able to make a key point of (agile) development accessible to the most important stakeholder: The customer, while giving us, the developers, a basic template for sanity checks. This is more than important, it is an absolute necessity for our survival as business entities, and in part even as hobbyists! Cucumber’s BDD tests probably don’t need an understanding of the programming language you happen to use, but abstract this away, since it is, in general, not needed at this stage.

Just remember The Law of Leaky Abstractions