5 ms·

Yes, cucumber is terrible. But I mean terrible in the "it not only doesn't solve the problem, it actually makes it worse" sense, not the "it's poorly written c

Yes, cucumber is terrible. But I mean terrible in the "it not only doesn't solve the problem, it actually makes it worse" sense, not the "it's poorly written code" sense. I bet it's a well-written (and tested!) piece of software, but I haven't actually looked. Cucumber tries to solve the problem of turning customer requirements into 'real code'. In exchange for that worthwhile benefit, it asks you to implement the most terrible, reg-ex based spaghetti code imaginable. The problem is that it doesn't solve the original problem AT ALL. And then you are left with terrible reg-ex driven spaghetti code. Like the Jamie Zawinski saying, "now you have two problems". The lesson here is that software development processes have to pass the 'human nature' test. The software industry has largely abandoned waterfall development because it just doesn't work well in practice. It doesn't work because people don't know perfectly what they want before they build it. Agile processes usually are much more efficient because they are more closely aligned to how humans solve problems in the real world. Cucumber suffers from the same issue of being disconnected with reality. In theory, you can find a customer who can give you perfectly written use cases and you can cut-and-paste those into your cukes. In practice, that never, ever works. So let's all stop wasting our time pretending it was a good idea now that it has been shown to not work.

chrismdp 13y ago
This entirely depends on how you write your step code. If you treat it like production code and aggressively refactor it, so you have minimal reuse of steps, lots of one or two-line steps, calling clean well factored plain Ruby code that actually does the work, you'll be a lot better off. This does take time to create, but in my experience having acceptance tests written in a form which is readable to anyone is very useful. I've even gone so far as to create a gem to display the features as the 'help' section of a website: https://github.com/chrismdp/rack-usermanual https://github.com/chrismdp/rack-usermanual
- cheald 13y ago
  And now you have three codebases to refactor and maintain. What's wrong with `rspec -f doc`?
  - goldvine 13y ago
    exactly. saves so much time. perfectly legible for most.
- jrochkind1 13y ago
  You weren't the first: https://www.relishapp.com/ https://www.relishapp.com/
  - chrismdp 13y ago
    Yeah, Relish is similar but not quite the same: it's a separate website rather than an integrated one.
dragonwriter 13y ago
> Cucumber tries to solve the problem of turning customer requirements into 'real code' No, it tries to solve the problem of narrowing the gap between objective, easily reusable tests and customer-understandable requirements. Insofar as it involves code, "real" or otherwise, that's a means to solving the problem, not the fundamental problem its trying to solve. > In theory, you can find a customer who can give you perfectly written use cases and you can cut-and-paste those into your cukes. The theory that "customers" on their own do this is flawed (and seems to be part of the we-don't-need-no-stinking-analysts school of software development theory); that's not a problem with cucumber or tools, its a problem with not having system/business analysts (which term is preferred depends on the environment, but they are the same thing) who work with customers to elicit requirements that the customers own and can validate but which the analysts helps them to shape into the needed structure.
joe_the_user 13y ago
In theory, this is a valuable thing, a bridge between the divergent worlds of developers and managers. In practice, however, I’ve never seen Cucumber used this way. Non-technical people don’t read code, no matter how easy it is to read. I don't know Cucumber at all but I find it fascinating how this software seems join a long list of hopeful but discarded "human readable coding" systems - both Cobol and SQL were touted back in the day as ways non-programmers could write code and consensus seems to be that the human-readable part just made things more difficult on the balance.
- reinhardt 13y ago
  SQL is nowhere near to being discarded; quite the contrary, for ex. Hive bringing it into the Hadoop ecosystem.
- stdbrouw 13y ago
  There are many, many people with limited programming skills who routinely do business analysis with SQL, and a whole suite of tools from e.g. Oracle to cater to exactly that audience. So while it's not really "human readable", in a sense it has achieved its goal of letting not-so-technical people do things that used to be reserved to computer scientists.

chrismdp 13y ago

This entirely depends on how you write your step code. If you treat it like production code and aggressively refactor it, so you have minimal reuse of steps, lots of one or two-line steps, calling clean well factored plain Ruby code that actually does the work, you'll be a lot better off. This does take time to create, but in my experience having acceptance tests written in a form which is readable to anyone is very useful. I've even gone so far as to create a gem to display the features as the 'help' section of a website: https://github.com/chrismdp/rack-usermanual https://github.com/chrismdp/rack-usermanual

cheald 13y ago
And now you have three codebases to refactor and maintain. What's wrong with `rspec -f doc`?
- goldvine 13y ago
  exactly. saves so much time. perfectly legible for most.
jrochkind1 13y ago
You weren't the first: https://www.relishapp.com/ https://www.relishapp.com/
- chrismdp 13y ago
  Yeah, Relish is similar but not quite the same: it's a separate website rather than an integrated one.

dragonwriter 13y ago

> Cucumber tries to solve the problem of turning customer requirements into 'real code' No, it tries to solve the problem of narrowing the gap between objective, easily reusable tests and customer-understandable requirements. Insofar as it involves code, "real" or otherwise, that's a means to solving the problem, not the fundamental problem its trying to solve. > In theory, you can find a customer who can give you perfectly written use cases and you can cut-and-paste those into your cukes. The theory that "customers" on their own do this is flawed (and seems to be part of the we-don't-need-no-stinking-analysts school of software development theory); that's not a problem with cucumber or tools, its a problem with not having system/business analysts (which term is preferred depends on the environment, but they are the same thing) who work with customers to elicit requirements that the customers own and can validate but which the analysts helps them to shape into the needed structure.

joe_the_user 13y ago

In theory, this is a valuable thing, a bridge between the divergent worlds of developers and managers. In practice, however, I’ve never seen Cucumber used this way. Non-technical people don’t read code, no matter how easy it is to read. I don't know Cucumber at all but I find it fascinating how this software seems join a long list of hopeful but discarded "human readable coding" systems - both Cobol and SQL were touted back in the day as ways non-programmers could write code and consensus seems to be that the human-readable part just made things more difficult on the balance.

reinhardt 13y ago
SQL is nowhere near to being discarded; quite the contrary, for ex. Hive bringing it into the Hadoop ecosystem.
stdbrouw 13y ago
There are many, many people with limited programming skills who routinely do business analysis with SQL, and a whole suite of tools from e.g. Oracle to cater to exactly that audience. So while it's not really "human readable", in a sense it has achieved its goal of letting not-so-technical people do things that used to be reserved to computer scientists.