I've been working in Rails since 1.2, and the vast majority of developers I've met have been of the opinion that cucumber sucks. There's a really vocal minority on the internet though, so you'd get the impression that it's pretty popular.
That said, almost every rails project I've worked on has had the cucumber gem included at some point, just not actively used.
IMHO the vocal Rails community puts too much emphasis on testing. I write tests for my code, but not as many as some would like. The RSpec book in particular is a gigantic load of crap. And I say this as a fan of comprehensive tests! The ridiculous lengths that book goes through in testing that codebreaker game are so detached from reality it makes my head hurt.
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.
> 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.
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:
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.
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.
Totally agree about the RSpec book, what a nightmare going through the examples, seems to me like they're trying to convince you that RSpec is good for you, but...I'm already reading the book, so just cut the crap and teach me how to write good tests based on realistic scenarios.
Perhaps, but I think more importantly it's just a time sink. You end up writing nearly all of the same test code, only reusing bits becomes more difficult thanks to the abstraction layer.
I believe this is because people don't properly consider who cucumber is for (business analyst), it was developed with a specific use case in mind. Aside from that, writing steps is ugly.
I've only suggest cucumber is extreme cases, and even then with caution, and not before mentioning Spinach as an alternative. https://github.com/codegram/spinach
Spinach operates with plain old ruby objects. They fix the two weakness of cucumber: Step maintainability & Step reusability.
That said, I seldomly use either, because I can easily write the same under one house with RSpec.
I have not read the book, but I respectfully disagree teaching a testing methodology should err towards over-testing. Your testing process should intelligently focus on the areas that most benefit from it, such as business domain logic, avoiding the pitfall of trying to cover e.g. your entire UI codebase.
No, but I should write one. Broadly speaking, I think test coverage in the real world, as practiced by effective programmers, is variable. One must use judgement to decide the appropriate level of test coverage. There are so many factors in making that judgement however that it's hard to distill.
The primary heuristic I look for is "Do I have enough tests that I can be reasonably sure these tests will fail if I break the code". That is the fundamental question! This is different than the RSpec books' approach which is more dogmatic and highly structured (you need to test every function, every entry point, pretty much every single thing). The thing is, the RSpec book approach does work! It works better in fact! It also is a colossal waste of time. I'd write tests like that if I was writing a trading platform for the NYSE, but almost no one does that sort of work.
Since I'm in the midst of writing a book (shameless plug http://exploringelasticsearch.com ) I don't have time to writ e that post unfortunately.
Your post makes me feel like you're missing the point of BDD.
The point of BDD isn't to "stop breaking the code". I think "coders" value "code" too much.
The point of BDD is to build understanding of the problem you're solving by enumerating behavioral ambiguities/edge cases up front, before you've invested time and emotion into a particular code approach.
You're using testable _behavior_ to drive the development of your code. More simply - test first, code second. Having a regression suite is a cool side effect.
Of course, this is just how it's "supposed to work." In real life YMMV. Whether or not you think there's much value in that methodology is another story - but if you are going to dismiss something, you have to dismiss it based on a relevant metric.
Yes, you have just regurgitated the rhetoric. But there are a lot of problems which the enumeration you describe is simply the wrong way to build understanding.
Basically, test the heck out of your domain model layer, and then do full stack acceptance tests above that to simulate the user using the app. If it's a web app use something like Capybara, if its a terminal app or some other interface, simulate that appropriately with some other kind of integration test.
The Rspec Book. Even though it advocates Cucumber (I kind of ignored that part), it really explains how to think about tests. How to approach unit tests, integration tests, and testing behavior not implementation. I don't write Ruby code or Ruby Specs, and I found the code and the book completely applicable to PHP and JavaScript testing.
I could be wrong, but the op was asking for a book recommendation beyond the Rspec book, because the root message of this thread says: "The Rspec book is a load of crap."
this is true in general. most internet noise comes from a vocal minority - being part of a vocal minority usually correlates to lack of skill and knowledge and not the other way around :/
That said, almost every rails project I've worked on has had the cucumber gem included at some point, just not actively used.
IMHO the vocal Rails community puts too much emphasis on testing. I write tests for my code, but not as many as some would like. The RSpec book in particular is a gigantic load of crap. And I say this as a fan of comprehensive tests! The ridiculous lengths that book goes through in testing that codebreaker game are so detached from reality it makes my head hurt.