4 ms·

TL;DR stop bitching about an acceptance testing tool when you're not using for acceptance testing. The problem isn't with Cucumber. The problem is your cukes s

TL;DR stop bitching about an acceptance testing tool when you're not using for acceptance testing. The problem isn't with Cucumber. The problem is your cukes suck. This is probably also a problem in your Rspec/Minitest/whatever tests. If you're using cucumber the way 90% of the cucumber tests I've ever seen (indeed, a great many i've written myself) are written, then you're writing integration tests, and probably crappy ones at that. Given a user And I go to some really cool page And I click on some button is NOT a domain test. Domains, for the most part, don't have 'users' (unless maybe your domain is drug addiction). Or 'pages' (unless you're in publishing). And they're definitely not about 'buttons' (unless you're a tailor.) [Yeah, you can probably find some domains where those are actual concepts. They're probably not all concepts in the same domain.] Write actual domain tests for your acceptance tests. Do this regardless of your framework—there's absolutely nothing preventing you from doing it rspec or anything else. Fuck step reuse (gherkin alternatives like spinach are great, specifically because the steps are isolated to the test.) If you don't want to write acceptance tests, and you feel comfortable with that, no biggie. Lots of people don't. But don't create a straw man out of Cucumber just because you don't understand layers of testing. This goes for Cucumber fanboys as well. Don't push cucumber into layers it doesn't belong. Its a domain testing tool. Not an integration test. definitely not a unit test. Don't push it on a team that doesn't want it. You can write the same kinds of tests in rspec. Disclaimer: I like cucumber. I am not using it in my current job because it wasn't a good fit for the company. I will probably use it again one day. I still write AT's. This: Given I hate cucumber And I post a scree against it Then the haters will rejoice is pretty much the same as this: describe "hating on cucumber" do it "produces a response" do given_i_hate_cucumber when_i_post_a_scree then_haters_rejoice end def given_i_hate_cucumber end #.... end

deleted 13y ago
[deleted]
- edu 13y ago
  use 2 spaces to make it a quote within a <pre> def mymethod :is_awesome end
  - karmajunkie 13y ago
    yeah, figured that out in the time between our posts :) thanks for the tip!
dragonwriter 13y ago
> This goes for Cucumber fanboys as well. Don't push cucumber into layers it doesn't belong. Its a domain testing tool. Not an integration test. Its far from the worst integration testing tool available, and I'm not really sure that there is a big difference in the requirements for an integration testing tool vs. a domain/acceptance tool; certainly, the ideal usage patterns into which the tools are embedded for those uses (including who should be writing tests: if you are trying to involve customers in test design, but your trying to do integration-style tests, that is likely to fail hard independently of tooling.)
- karmajunkie 13y ago
  It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I have a rule on my teams that integration tests are allowed to know about some internals and use them. Acceptance test steps are not allowed to know about anything that isn't an accepted part of the domain vocabulary and the user interface of the SUT. There's an advantage to this as well, if you practice something that approximates DDD: you can use the same test to hit your domain library as your user interface. The step implementations are different, obviously, but the gherkin test is the same. Also, I definitely agree with those who have stated elsewhere that customer collaboration is a red herring. I've guided customer discussions with cukes before (e.g. talking about edge cases and aspects they haven't thought about), but never has customers writing cukes been a good experience.
  - dragonwriter 13y ago
    > It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I agree that there is a big difference (I'd describe it differently because I don't think of ITs as being about code, I think of UT as being about code, ITs as being about architecture, and ATs as being about domain concepts, but that's, arguably, quibbling); I just think its a difference that often manifests more in terms of the organization of the who-does-what-and-how outside of the tool but which, between ITs and ATs, doesn't necessarily make a huge difference in desirable tool features. (Particularly, I think than non-code language for tests can have value for ITs, though the style of the language and its audience is different than for ATs.)
_stfu_donnie 13y ago
yeah, I think the code examples are contrived, but I don't think that's enough to just jump to "your cukes suck," guess I shouldn't be surprised to find a knee-jerk reaction like that on HN. The damn example you posted at the end of an RSpec test that has a bunch of defined methods IS EXACTLY WHAT THE AUTHOR IS SAYING! "Cucumber is just a way to wrap RSpec tests with a non-technical syntax. Any supposed benefits of it go to waste because code is only interesting to those who are working in it. Quit writing cukes unless you can honestly say that there is someone reading them who would not understand pure Ruby." Who exactly are you arguing against?
- karmajunkie 13y ago
  The authors argument is "You can do this with another tool so tool X is a bad idea." I disagree. The language behind testing is important. When you test code, the language is code; when you test domain, the language is natural language. My advice to teams who can't use cucumber for doing domain testing is to approximate the same thing in rspec, even though its not the best/optimal tool for it. Gherkin (not just cucumber) is NOT just about wrapping rspec tests with a non-technical syntax. Also, as contrived as his examples are, he still managed to illustrate exactly the problem inherent in most of the cukes i've ever seen: they're about clicking buttons and navigating a browser. That's not domain. (To be fair, the cucumber team didn't do themselves any favors there by adding the web_steps.rb to their installation process way back when—its long gone now but the legacy lives on.)
awj 13y ago
Arguments based on "X doesn't suck, 90% of people are just doing it wrong" aren't convincing to me. If nearly everyone is using a tool incorrectly, the problem is still with the tool. Maybe the tool doesn't suck, but obviously the documentation and education around it does.
- karmajunkie 13y ago
  I'd agree with that. The education around proper utility of cucumber is definitely a problem.
  - astrodust 13y ago
    Proper utility: Do not use. I've seen people try and fail to use Cucumber effectively. Now, Cucumber is a really impressive implementation, but it's a fundamentally flawed idea. You cannot pivot your requirements from business talk "As a blah I want X" into functional tests without a lot of shear. You may as well write your test descriptions in Farsi or Russian for a team that only speaks English. They make no sense. Functional requirements should set the groundwork, but they shouldn't serve as the template for construction. You convert these requirements into a format and language understood by developers. If you can preserve some kind of mapping between the original requirement and the myriad of things that had to be implemented to make that feature work, you've done something amazing. Sadly, Cucumber doesn't let you do that.
    - karmajunkie 13y ago
      Your premise is fundamentally flawed if you're using "functional tests" as a technical term (cucumber is not a functional testing tool) and just wrong if you're using it as a descriptor. Just because you've seen people try and fail to use cucumber effectively doesn't mean it can't be done. I would go so far as to say if you can't do it, you should reexamine how both how you're writing your tests, and how you're writing your application.
- dragonwriter 13y ago
  > Arguments based on "X doesn't suck, 90% of people are just doing it wrong" aren't convincing to me. The argument isn't som much that Cucumber doesn't suck, but people are using it wrong, but that Cucumber does suck for what people are complaining about it sucking for, but that Cucumber isn't designed or promoted for that use. Its "yes, hammers suck for connecting things with machine screws, but that's not what they're for", not "hammers don't really suck for connecting things with machine screws, its just most people are holding the hammer wrong when they try to do that".
jessaustin 13y ago
Could you point to more information about domain testing, or even what the domain concept means in this context? Is it about what I've heard described by "SMEs" as "business rules"?

deleted 13y ago

[deleted]

edu 13y ago
use 2 spaces to make it a quote within a <pre> def mymethod :is_awesome end
- karmajunkie 13y ago
  yeah, figured that out in the time between our posts :) thanks for the tip!

dragonwriter 13y ago

> This goes for Cucumber fanboys as well. Don't push cucumber into layers it doesn't belong. Its a domain testing tool. Not an integration test. Its far from the worst integration testing tool available, and I'm not really sure that there is a big difference in the requirements for an integration testing tool vs. a domain/acceptance tool; certainly, the ideal usage patterns into which the tools are embedded for those uses (including who should be writing tests: if you are trying to involve customers in test design, but your trying to do integration-style tests, that is likely to fail hard independently of tooling.)

karmajunkie 13y ago
It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I have a rule on my teams that integration tests are allowed to know about some internals and use them. Acceptance test steps are not allowed to know about anything that isn't an accepted part of the domain vocabulary and the user interface of the SUT. There's an advantage to this as well, if you practice something that approximates DDD: you can use the same test to hit your domain library as your user interface. The step implementations are different, obviously, but the gherkin test is the same. Also, I definitely agree with those who have stated elsewhere that customer collaboration is a red herring. I've guided customer discussions with cukes before (e.g. talking about edge cases and aspects they haven't thought about), but never has customers writing cukes been a good experience.
- dragonwriter 13y ago
  > It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I agree that there is a big difference (I'd describe it differently because I don't think of ITs as being about code, I think of UT as being about code, ITs as being about architecture, and ATs as being about domain concepts, but that's, arguably, quibbling); I just think its a difference that often manifests more in terms of the organization of the who-does-what-and-how outside of the tool but which, between ITs and ATs, doesn't necessarily make a huge difference in desirable tool features. (Particularly, I think than non-code language for tests can have value for ITs, though the style of the language and its audience is different than for ATs.)

_stfu_donnie 13y ago

yeah, I think the code examples are contrived, but I don't think that's enough to just jump to "your cukes suck," guess I shouldn't be surprised to find a knee-jerk reaction like that on HN. The damn example you posted at the end of an RSpec test that has a bunch of defined methods IS EXACTLY WHAT THE AUTHOR IS SAYING! "Cucumber is just a way to wrap RSpec tests with a non-technical syntax. Any supposed benefits of it go to waste because code is only interesting to those who are working in it. Quit writing cukes unless you can honestly say that there is someone reading them who would not understand pure Ruby." Who exactly are you arguing against?

karmajunkie 13y ago
The authors argument is "You can do this with another tool so tool X is a bad idea." I disagree. The language behind testing is important. When you test code, the language is code; when you test domain, the language is natural language. My advice to teams who can't use cucumber for doing domain testing is to approximate the same thing in rspec, even though its not the best/optimal tool for it. Gherkin (not just cucumber) is NOT just about wrapping rspec tests with a non-technical syntax. Also, as contrived as his examples are, he still managed to illustrate exactly the problem inherent in most of the cukes i've ever seen: they're about clicking buttons and navigating a browser. That's not domain. (To be fair, the cucumber team didn't do themselves any favors there by adding the web_steps.rb to their installation process way back when—its long gone now but the legacy lives on.)

awj 13y ago

Arguments based on "X doesn't suck, 90% of people are just doing it wrong" aren't convincing to me. If nearly everyone is using a tool incorrectly, the problem is still with the tool. Maybe the tool doesn't suck, but obviously the documentation and education around it does.

karmajunkie 13y ago
I'd agree with that. The education around proper utility of cucumber is definitely a problem.
- astrodust 13y ago
  Proper utility: Do not use. I've seen people try and fail to use Cucumber effectively. Now, Cucumber is a really impressive implementation, but it's a fundamentally flawed idea. You cannot pivot your requirements from business talk "As a blah I want X" into functional tests without a lot of shear. You may as well write your test descriptions in Farsi or Russian for a team that only speaks English. They make no sense. Functional requirements should set the groundwork, but they shouldn't serve as the template for construction. You convert these requirements into a format and language understood by developers. If you can preserve some kind of mapping between the original requirement and the myriad of things that had to be implemented to make that feature work, you've done something amazing. Sadly, Cucumber doesn't let you do that.
  - karmajunkie 13y ago
    Your premise is fundamentally flawed if you're using "functional tests" as a technical term (cucumber is not a functional testing tool) and just wrong if you're using it as a descriptor. Just because you've seen people try and fail to use cucumber effectively doesn't mean it can't be done. I would go so far as to say if you can't do it, you should reexamine how both how you're writing your tests, and how you're writing your application.
dragonwriter 13y ago
> Arguments based on "X doesn't suck, 90% of people are just doing it wrong" aren't convincing to me. The argument isn't som much that Cucumber doesn't suck, but people are using it wrong, but that Cucumber does suck for what people are complaining about it sucking for, but that Cucumber isn't designed or promoted for that use. Its "yes, hammers suck for connecting things with machine screws, but that's not what they're for", not "hammers don't really suck for connecting things with machine screws, its just most people are holding the hammer wrong when they try to do that".

jessaustin 13y ago

Could you point to more information about domain testing, or even what the domain concept means in this context? Is it about what I've heard described by "SMEs" as "business rules"?