I have a really hard time getting behind the names of many of the open source test tools that are out there. Here I want to talk about that just a little bit and what I’ve been doing to combat that. I do realize that I am probably in the vast minority of people who are concerned about this issue.
Speaking here in an obviously heavily opinionated way, if you look at many of the open source test solutions out there, people either opt for tool names that are attempting to be descriptive of how they work (page-object) or clever in terms of “branding” (site_prism) or an attempt to just be cryptically ‘clever’ (Kookaburra). The latter apparently being a conflation of Cucumber and Capybara. Or something.
You have others that name themselves within the odd ecosystem that is the Ruby world of gems (Cucumber, Capybara, Steak, Turnip, etc). I’m sure everyone feels they are being terribly clever and witty but once you get past that, those names leave a bad taste for me. I believe that Cucumber is a very important tool in that it promoted some exciting things in the industry. However, it’s also one of the most stupidly named tools I’ve come across. To me that disparity between its function and its name is all the more apparent because I do think it’s a good tool.
Contrast that name with, say, SpecFlow in the .NET world, which I do think is a much better name, or JBehave in the Java world, even though I get a little tired of Java developers feeling they have to preface each of their tools with a “J”.
Rather than complain, lead by example …
So what have I been doing to combat this issue? Well, perhaps not much originally. I had worked on a tool I called Symbiont. I “cleverly” described it as “an endosymbiotic facultative library for web application testing.” I even took time to explain what the heck that even meant on the GitHub page for it.
That should have been my first clue.
Now, I will say that there was at least some thought here: Symbiont sort of “attaches to” whatever test library you wanted it to and then attached itself to certain page or activity definitions. But still. Symbiont? Really?
Yeah.
But Symbiont was the “toy”, if you will. Symbiont was the thing that allowed me to realize I had a good solution. And it was time to professionalize it once I had settled around what I actually wanted the tool to provide.
I had, at one point, changed that to a tool called Fluent. I named it that because that was indicative of what it provided, without getting into how. Fluent was predicated upon the notion of a fluent interface, which I believe all good test solutions should be providing. (I was actually pleasantly surprised that no one had taken that specific name for a gem.)
Now, you might argue: but now anyone who learned Symbiont has to learn Fluent. Yes — but they both share the same interface. Good design means you program to an interface and make that the contract. The public API of Symbiont and Fluent are largely identical, with Fluent simply refining it all. Ironically I ended up going with Symbiont as my tool of choice.
I also have a tool called Lucid, which is pretty much a clone of Cucumber in many ways, except without the name, with a few extra features, and without the Cucumber developer bias that it’s not a testing tool. Lucid is a testing tool, just as Cucumber is, even if the primary maintainers don’t want to admit it and even though their own “Cucumber Book” repeatedly states it.
Lucid promotes what it does, not how it does it. It promotes the concept of lucid testing: making things clear and understandable by providing a single source of truth for requirements-as-test that allows you built-in traceability and a communication mechanism predicated upon a shared notion of quality. All of that is important because the very name leads you into the discussion that testing is a design activity as well as an execution activity. Testing, as a design activity, is all about collaboration. Collaboration is what lucid testing focuses upon. You are testing people’s understanding of a shared notion of quality as it gets encoded as actionable statements that you can call acceptance tests. Calling Lucid a testing tool is actually NOT a bad thing, as long as people have a broad view of testing and realize that testing is a multi-faceted activity.
Having that same discussion around a tool called Cucumber just falls flat, at least in my experience.
A wee bit picky, are we?
Okay, now let’s back up for a second. I’m focusing a lot on names here. And surely what matters is what the tool does, not what it is called, right? After all, these are just names. That’s true. They are. And what they are named does not make the tools more or less efficacious.
But I find the way people treat tools, at least when you get into professional environments, does matter. Expectations are set. A level of professionalism does come into play. I have had much more luck getting companies and teams to rally around a tool called Lucid (by which I promote Lucid Testing) and the use of fluent interfaces (with a tool called Fluent) then if I go in and tell them I want to base my strategy around Cucumber and Capybara.
I can just hear the decision makers. “Huh? So … he wants to … what? Feed fruit to a rodent?” (In case the reference is lost, a capybara is a rodent that is basically a water hog. And, yes, Cucumbers are scientifically classified as a fruit and not a vegetable.)
Anyway, this is all why my Cucumber clone is called Lucid. Because that’s what it does – it makes requirements and testing lucid. Use of this solution is one means by which our testing becomes “lucid” — by which is meant compressible, expressive, intent-revealing, business-focused, design-guiding, quality-oriented. When people talk about my tool, they are forced to use a term that guides their thinking. I can remind them that the point of Lucid (the tool) is being lucid (an approach).
And that’s why Fluent is called as it is. What it does is provide a fluent interface to allow for the test logic behind the scenes to also be compressible, expressive and intent-revealing.
Will Lucid and Fluent ever go anywhere? Will they replace Cucumber or whatever else? Probably not, but that’s not the intent. Competing tools like Lettuce, Freshen, Lime, Spinach, and Rutabaga all provide alternatives to Cucumber in various ways and none of them have displaced it, nor was that likely their intent.
By the way: notice how many of these tool makers feel they have to somehow stay within that naming nomenclature? Cucumber has managed to spawn a whole host of tools that, if nothing else, can make me think about food. They don’t make me think any more deeply about testing or the kinds of things I want a testing tool solution to provide.
Perhaps I’m over-sensitive to this kind of thing, but I find this state of affairs somewhat sad.
Jeff — I’m glad to see someone outright say this. I’ve worked at two places that wouldn’t even consider Cucumber because it was a tool name that no one could take seriously. Like you I realize that the name doesn’t impact how useful a tool it is. But perceptions are there nonetheless. Even without that, however, I would go so far as to say something you didn’t: which is that these tool developers are lazy. All the copycats of Cucumber (or whatever other tool) tend to just name their own tool as some meaningless variation. I think I read that Cucumber was named basically on a whim. So maybe you’re in the minority on this, but I’m right there with you! 🙂
As far as the lazy, I would actually rather argue that the developers of the various solutions were simply working within the established “ecosystem” of names. For example, the tool Steak was actually done in reaction to the fruit/vegetable ideas that sprung up around Cucumber, Spinach, etc. Other tools, like CukeSalad, clearly attempt to be clever within that context. This is perhaps not much different from how Watir had various solutions accrete around it with names with WatirFront, WET, and so on. That said, I have no idea what to make of tools like ManaMana!
The ironic thing is that Cucumber was born (I think anyway) in some ways from RBehave being merged into RSpec, which became the Story Runner. The irony here being that at least those names were somewhat indicative of something useful. Then from all that we get … Cucumber. :-/ Makes no sense. I’ll be honest here: I don’t like Cucumber as an abstraction layer and thus I probably wouldn’t like your Lucid tool either. But I can at least get behind a name like Lucid whereas a name like Cucumber just gives me a reason to dismiss it.
What I find ironic is that a tool like Cucumber, which is supposed to be all about taking care with how things are described, describes itself so poorly by its name. I too have read the Cucumber book and saw how it says it’s a testing tool but then you find the most ardent supports of it on the Cukes newsgroup going out of their way to say it’s not a testing tool at all.
There is truth to this, I think. Cucumber promotes the practice of talking in a domain language and yet it itself is not named in any way that is indicative of its domain.
I don’t think your Symbiont name is that bad. Put it up against Selenium’s name which was a way to take a jab at the company Mercury (original makers of WinRunner and QTP), the idea being that if you were using their products you had “mercury poisoning” and needed an intake of selenium. I think there’s a balance between being creative with tool names and being somewhat indicative of what the tool does, even if you have to explain it. Symbiont makes sense when I read your description on GitHub. Cucumber in no way makes sense. Another example is Behat, which is a Cucumber clone for PHP. Doesn’t make a whole lot of sense to me. Or consider Robot Framework, which has a lot of cool ideas — but the name makes little sense. (And is often confused in discussions with Rational Robot.) Sahi is an example, which according to their web site, means ‘right’ or ‘correct’ in the Hindi language. That’s probably not so bad. So, yes, Cucumber is a horrid name and I actually know many people who think so. But it’s often perceived as the only game in town, at least for that kind of solution in the Ruby world. So people just live with it.
As far as the “perceived as the only game in town”, it’s an interesting point because the various competitors do often have distinguishing characteristics. Spinach, for example, removes regular expressions entirely. It also does not allow tables or scenario outlines. Turnip allows you to use Gherkin as part of RSpec. It does not allow regular expressions but does allow placeholders. Rutabaga is actually an inversion of control mechanism for Turnip. So those are tools that have functional differences. Lime attempts to remove separate feature files and simply have you write the features directly in Ruby code. Lettuce, on the other hand, is “simply” a version of Cucumber done in Python.
So while there are many games in town, it’s not clear how to distinguish them, at least by their name. Yet, to be fair, what should those tools be called to distinguish them? If I turn my critical comments on my own tool set, what exactly does Lucid indicate about how different it is or is not from Cucumber?
For me this comes down to the intent of the tool and what approach you are attempting to promote with the tool, whether that be in terms of test design and communication or test execution.
Perhaps a different viewpoint, but I’ve always viewed it that Cucumber is not a testing tool. Based on your comments regarding Lucid and how it is a testing tool, I started reading a bit more of your material. I see how your particular focus on testing allowed for a name that focused on aspects of testing. Cucumber wasn’t focusing on that so maybe that’s why they chose how they did? I still can’t explain a name like “Cucumber” since I’ll be the first to agree that the name is moronic. I honestly think it was just a case of the developers not thinking far enough ahead. It sounds to me like the name of a tool where someone was not thinking about what they wanted.
Regarding that last point, I agree. I think if you don’t have a wider focus for your tool, tied into an approach you are hoping to promote, you end up with names like “Cucumber.”
As far as my focus on Lucid versus that of Cucumber, in my view that focus should not be seen as different, although I have found via discussions that the Cucumber maintainers do not think much like testers at all, and barely think like business analysts. They definitely think like developers first and foremost.
Lucid is about the idea of having the actionable components of requirements written as tests. Anything you want to take time to specify you also presumably want to take time to test. Thus when your specification becomes your test, you build in traceability and promote a single source of truth around a shared notion of quality. That, to me, is what “being lucid” is all about. If anything, Lucid (the tool) promotes the idea that testing is a design activity focused on communication of intent.
What you said there is definitely more of a vision than I think Cucumber had. The developers just didn’t have their eye on the future enough. I think that’s a problem that’s plagued its development though given that the lead developer, Aslak Hellesoy, is a bit annoying. I’ve never found him very responsive unless he already agrees with you and he’s very touchy. Much of the effort has gone into the disaster that is Cucumber-JVM, so that might be part of it.
Well, I hear you. I guess I don’t want to turn this into a personal thing in terms of individual personalities. Sometimes I think it takes a headstrong — and even annoying! — person to shepherd these projects through their early life. There’s a balance, though, I’ll give you that.
I’ve seen a little of what you discuss in the Cucumber community as a whole but, as I said in response to another comment, I think a lot of it is simply that the core maintainers think as developers first, sort of as testers second, and only very distantly as business analysts.
This, however, is something that is common to the industry as a whole: testers have not been technical enough to develop test solutions, so it has fallen to developers to do so. (Yes, I’m painting with a very broad brush there.) Sometimes, too, you simply don’t know which (if any!) of your ideas are going to take off. As I said, I started with “Symbiont” and ended up wanting to professionalize it a bit more.
Part of it may also be the arenas in which people introduce these tools. Most of the organizations I see people write up experiences with, they tend to be smaller, a bit more dynamic perhaps. I’m usually in a position of introduced them to quite large organizations. That may or may not make a difference, of course, but I’ve found larger organizations have trouble taking a tool called “Cucumber” seriously.
Hey Jeff! I saw your post on the Cukes google groups and it seems you’re considering whether to attempt more merges of Lucid into Cucumber? My two cents: I wouldn’t. Lucid has traction among various groups at various companies. As you know, mine is one of them! 🙂 I can tell you that there is definitely backlash against Cucumber in many places I’ve consulted at, especially those that are not “start up types.” This has intensified with the announcement of Cucumber Pro. Are you still thinking of doing the Lucid Lean thing you were talking about?
In any case, stay the course, my friend!
For awhile I was toying with attempting to merge some aspects of Lucid into Cucumber via pull requests. That said, right now Lucid can be tailored to work exactly like Cucumber. (For example, I alias my “Domain” to Cucumber’s “World”. People can use env.rb instead of my driver.rb. The directory structure can be made to work exactly as Cucumber’s default does. People can use the .feature extension instead of Lucid’s default .spec extension. Etc.)
The point there being I can leverage the Cucumber ecosystem. But, on the other hand, there is still a slight level of indirection there for people who are used to Cucumber.
Currently I am still investigating the “Lucid Lean” concept. It sort of combines ideas of Spinach and Turnip but while retaining more of the flexibility that Cucumber allows. For example, I’m convinced that the reason most people dislike Spinach entirely is that it’s just way too opinionated — not allowing regular expressions, scenario outlines or tables. Removing choice from people is rarely good.
As far as Cucumber Pro, I haven’t followed that as much as it doesn’t interest me if only because I feel those solutions should be freely available. That said, I have nothing against the approach they are taking. But Lucid will eventually get a friendly interface and that interface will certainly not require people paying for it.