Last night I was reviewing a draft of a paper for publication, and I saw the claim that cucumber tests could be written in English, and felt compelled to reply:
Why is it that when I correct the grammar and capitalization of these automated tests expressed in English, they break?
I thought it was worth elaborating on here.
Wait, what's a Cucumber test? And it allows me to code in plain English! Cool!
Well, no, they don't. That's the problem. But let me back up.
Cucumber is framework for behavior driven development. The idea is to specify what the program does, up front, in
something like English, developed with the programmers, testers, analysts and tests
in collaboration.
Make no mistake, though - you're writing code. Say, for example, your cucumber test is something like this:??Given I have entered 50 into the calculator?And I have entered 70 into the calculator?When I press add?Then the result should be 120 on the screen
----> I have to admit, this looks a lot like English. Yet it is computer code; the cucumber engine converts "I have entered (.*) into the calculator" into a function call in Ruby, and, of course, someone needs to write that function in Ruby.
Now this is a huge improvement in readability. I'm not denying that. It's just not English.
The common programmer response is "of course it's not English, Matt. Every grown-up in the industry, and most of the toddlers, will realize this is writing code that needs to be parsed into a syntax tree. Cucumber provides some sugar so instead of writing enter_calculator(50); the customers can write "enter 50 into the calculator" This enables business collaboration. What's your deal?" (They usually say it more politely.)
And, to be fair, the rough draft I saw said exactly that, using the term "it's not magic" and explaining that some programmer would need to code up the back end.
Why does this bug me?
The entire history of software is filled with claims that programmers could be eliminated, and 'plain' business people would be able to develop software themselves. This is an old idea; in graduate school we were studying
Transformational Specification, for gosh sakes, which was supposed to enable people to write a spec in "something like English", apply a series of transforms, and, like magic, code would plop out.
It turns out that this idea sells tools, but it doesn't pan out.
It's a recurring theme.
I wrote this in two thousand and five, and believe it still holds today:
There have been numerous technologies that promised to allow the users to write code, if they could just express themselves in a nice, clear, precise, rational and structured way.
The thing is, few people *can* express themselves in a formal grammer that can be compiled, syntax checked, and do what the person actually expects. In fact, it is a skill which few people have an interest developing. When we were developing those skills, most people were outside playing football, and asking "what's wrong with Joe? Why doens't he want to play football?"
We generally call people with those skills "Programmers", "Mathmaticians", or "Engineers."
So, every time a tool comes out that promises to eliminate the developers -
CASE-based Code Generators in the early 1980's?SQL in the 1980's?Visual Basic in the Early 1990's?MS Frontpage in the late 1990's?Crystal Reports about the same time?Business Intellegence Tools Today
You find that the buisness buys the tool, asks the programmer to figure it out, and then the programmer programs in the new tool - albeit at a higher, more powerful level. Occasionally, a business user picks up the tool, but they generally give up the old job in order to do the new one, and within a few years their title changes to programming or they transfer to the IS Department.
Programmers will continue to be demand for a long time, my friends. Economic trends may make this field hard, businesss may not appreciate development enough and try to push costs down, data center management and system administration may get easier and require less people, but programming will be in demand ... we just might have to call it something else, like "Business Analytics Specialist"
(That was more prescient that I had originally realized -- it turns out that SQL was originally SEQUEL, the Structure English Query Language. Eventually IBM took out the E, for, among a few legal/copyright issues with the term SEQUEL, it turns out that production SQL isn't actually very much like English.)
Searching for Cucumber Software "in Plain English" last night, I found eighteen thousand hits. (Cucumber software "something like English" returns two, but they are exclusively about a little green vegetable. Seriously.)
What does this have to do with testing?
Well, there are a few problems. First, when we trivialize the complex work that testers actually do, we're looking to
subtly change our role or even lose it over time.
More importantly, though, this is not my first rodeo. In my life experience, when people make claims that don't hold water, or can be easily disproven, bad things happen.
We end up with software that sits on a shelf for ten years, unused, or people that are laid off without causes, and the entire organization scrambles to do the work -- or finger-pointing, or, sometimes, people hired without cause.
Since this is talking about automation, development, and testing, this thing is happening in our backyard.
I don't want to be hit by the backwash.
Oh, Matt, don't worry about it!
Now, some will claim that "plain English" doesn't actually mean "prose", that the statement is clear.
That's the thing about real English; it can be interpreted in different ways by different people. That is exactly what computer programs are not -- they are expected to be specific, unambiguous statements creating a precise correct behavior. Using tools to convert the syntax, to, say, allow us to add spaces between words and remove the parenthesis is great.
English, however, it ain't.
Yes, the claims bug me as a tester. More importantly, though, they bug me as a writer.
All I'm asking is for us to drop the "in plain english" terminology from Domain Specific Languages, and start talking about "a language closer to English that business people can more easily understand and contribute to."
Of course, that it's a fair point that technical folks are business people, so that sentence has it's own problems as well.
As always, more to come. :-)