So far, I've been using RSpec for testing my Rails apps simply because
that's what railstutorial.org emphasizes.

However, I am in the process of trying out Cucumber. I like the fact that
it's in plain English, and this is an asset for communicating with clients
or other people who aren't Rubyists. Migrating to Cucumber sounds like a
good idea.

I'm curious about what you prefer. Do any of you know Cucumber well, yet
still prefer RSpec? If so, why?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/de3edd1e-f7a3-4e94-b0b6-094581954126%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Tamara Temple at Aug 22, 2013 at 9:48 pm

    On Aug 22, 2013, at 4:29 PM, "Jason Hsu, Android developer" wrote:

    So far, I've been using RSpec for testing my Rails apps simply because that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact that it's in plain English, and this is an asset for communicating with clients or other people who aren't Rubyists. Migrating to Cucumber sounds like a good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well, yet still prefer RSpec? If so, why?
    Jason, I highly recommend picking up The RSpec Book, published by Pragmatic Programmers [1]. It discusses both RSpec and Cucumber: when and how to use both of them. They actually work well together, and complement each other in many ways.

    For me, RSpec is the way I like to perform unit and functional testing, while Cucumber, with the Gherkin language, seems ideal for describing and testing the larger elements of the application, and are quite well suited to documenting stories as one does in Agile development, and implementing them to provide acceptance tests for features and releases. Cucumber is useful also to drive external testing of web applications via Capybara or Watir, and also for driving command line tools via Aruba.

    So, for me, it's not really one *or* the other, it's both, and deciding what level of testing is needed and how easy it will be to implement that test. It is possible, I suppose, to use only one of them, but the level of detail expressible in RSpec seems to me to be ideal at the lowest level, and the large scale expressibility with Gherkin makes Cucumber more relevant to higher levels of abstraction that can be written and read by non-technical people fairly easily.

    [1] http://pragprog.com/book/achbd/the-rspec-book


    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/71FAB1F2-773F-4257-BD1B-4175066845C1%40gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Emil S at Aug 23, 2013 at 5:21 am
    My rule of thumb : Cucumber for integration testing ( output =
    documentation of features ) and RSpec for unit testing ( output =
    documentation of code )

    On 23 August 2013 03:18, Tamara Temple wrote:


    On Aug 22, 2013, at 4:29 PM, "Jason Hsu, Android developer" <
    jhsu802701@gmail.com> wrote:
    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.
    However, I am in the process of trying out Cucumber. I like the fact
    that it's in plain English, and this is an asset for communicating with
    clients or other people who aren't Rubyists. Migrating to Cucumber sounds
    like a good idea.
    I'm curious about what you prefer. Do any of you know Cucumber well,
    yet still prefer RSpec? If so, why?

    Jason, I highly recommend picking up The RSpec Book, published by
    Pragmatic Programmers [1]. It discusses both RSpec and Cucumber: when and
    how to use both of them. They actually work well together, and complement
    each other in many ways.

    For me, RSpec is the way I like to perform unit and functional testing,
    while Cucumber, with the Gherkin language, seems ideal for describing and
    testing the larger elements of the application, and are quite well suited
    to documenting stories as one does in Agile development, and implementing
    them to provide acceptance tests for features and releases. Cucumber is
    useful also to drive external testing of web applications via Capybara or
    Watir, and also for driving command line tools via Aruba.

    So, for me, it's not really one *or* the other, it's both, and deciding
    what level of testing is needed and how easy it will be to implement that
    test. It is possible, I suppose, to use only one of them, but the level of
    detail expressible in RSpec seems to me to be ideal at the lowest level,
    and the large scale expressibility with Gherkin makes Cucumber more
    relevant to higher levels of abstraction that can be written and read by
    non-technical people fairly easily.

    [1] http://pragprog.com/book/achbd/the-rspec-book


    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/71FAB1F2-773F-4257-BD1B-4175066845C1%40gmail.com
    .
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAJ%3Dox-C2hMs3AWFQERsrqP5zGtpxN%3DHwMVtfwUA3o8cXXEnTfA%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ilya Igonkin at Aug 23, 2013 at 10:58 am
    I know a lot people may disagree, but I believe that using Cucumber is
    counterproductive as writing plain English text and then parsing it with
    regular expressions is somewhat overkill and error prone. I think anyone
    should use Cucumber only if they have a strong reason to. And some well
    known Rails developers such as Michael Hartl (Ruby on Rails Tutorial) and
    Aaron Sumner (Everyday Rails Testing with RSpec) are rather agree on that.
    On Fri, Aug 23, 2013 at 3:29 AM, Jason Hsu, Android developer wrote:

    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact that
    it's in plain English, and this is an asset for communicating with clients
    or other people who aren't Rubyists. Migrating to Cucumber sounds like a
    good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well, yet
    still prefer RSpec? If so, why?

    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/de3edd1e-f7a3-4e94-b0b6-094581954126%40googlegroups.com
    .
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAFp%3DAzNdFTvOTbHO8ZqMVtvGVRHOamqq1n7rzLEnWtNVF%2B9MzA%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Aronson at Aug 23, 2013 at 11:54 am

    On Fri, Aug 23, 2013 at 4:15 AM, Ilya Igonkin wrote:

    using Cucumber is counterproductive as writing plain English
    text and then parsing it with regular expressions is somewhat
    overkill and error prone. I think anyone should use Cucumber
    only if they have a strong reason to.
    Agreed! I usually do my acceptance-level tests in straight Ruby.
    (Though with the aid of gems like Capybara and so on for page content
    access, click simulation, form filling, etc.) The Cucumber (tempted
    to just say Cucu!) way would be to write:

       When I build a new large, blue, left-handed veeblefetzer, with a
    belt in the back

    Then I'd have to create a step definition that has to parse the size,
    color, handedness, and/or belting (or lack thereof) of a new
    veeblefetzer, with those various things all being optional (else I'd
    have to specify them when I don't care), and look at whether I said
    "create" or "build" to tell which it should do. Alternately, a BUNCH
    of step defs so they're not optional but key off the regex being
    satisfied. By skipping Cucumber altogether, I can just write a normal
    Ruby function call:

       when_i_make_a_veeblefetzer(size: :large,
                                  belt: :in_the_back,
                                  save: false)

    This is close enough to plain English that any non-geek should be able
    to understand it just fine. I could even make the capitalization
    "normal" if they want. Anyway, then I make a normal Ruby function
    like "def when_i_make_a_veeblefetzer(options)" and have it parse them
    as a plain old hash, getting anything unspecified from a hash of
    defaults (such as how this one's color and handedness don't matter).
    No need to futz around with complex regexes. Usually I can pass most
    of the options-hash straight to either FactoryGirl or the class's .new
    method, other than filtering out "save" to determine whether to call
    build or create.

    My tests may have 99 problems, but maintaining hairy regexes ain't one.

    -Dave

    --
    Dave Aronson, the T. Rex of Codosaurus LLC,
    secret-cleared freelance software developer
    taking contracts in or near NoVa or remote.
    See information at http://www.Codosaur.us/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAHxKQiioeVnac9Ut1tPRVkKW_O50qV4ojfymD1iC1yOhUJgG%3Dw%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rekha Benada at Aug 23, 2013 at 9:01 pm
    Rspec is a popular framework for unit testing and Cucumber is used for
    integration testing and behavior driven development

    Unit tests with rspec confirm that small, discrete portion continue working
    as developers add features.
    Integration tests built with cucumber determine wether the application's
    features work as expected,testing the application from user point of view.

    Thanks
    On Thursday, August 22, 2013 2:29:04 PM UTC-7, Jason Hsu, Android developer
    wrote:
    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact that
    it's in plain English, and this is an asset for communicating with clients
    or other people who aren't Rubyists. Migrating to Cucumber sounds like a
    good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well, yet
    still prefer RSpec? If so, why?
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/38f9f99b-2dd0-46ae-9d79-bf20088a390d%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ilya Igonkin at Aug 24, 2013 at 6:54 am

    On Sat, Aug 24, 2013 at 2:58 AM, Rekha Benada wrote:

    Rspec is a popular framework for unit testing and Cucumber is used for
    integration testing and behavior driven development
    It's pretty strange to hear since RSpec description is "BDD for Ruby". More
    than that, recent versions of RSpec for Rails (v2.12.0 or greater) support
    feature specs for integration testing whose syntax is very similar to
    Cucumber features. For more information see:
    http://www.andylindeman.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html

    Unit tests with rspec confirm that small, discrete portion continue
    working as developers add features.
    Integration tests built with cucumber determine wether the application's
    features work as expected,testing the application from user point of view.

    Thanks
    On Thursday, August 22, 2013 2:29:04 PM UTC-7, Jason Hsu, Android
    developer wrote:
    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact
    that it's in plain English, and this is an asset for communicating with
    clients or other people who aren't Rubyists. Migrating to Cucumber sounds
    like a good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well, yet
    still prefer RSpec? If so, why?
    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/38f9f99b-2dd0-46ae-9d79-bf20088a390d%40googlegroups.com
    .

    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAFp%3DAzPE4ytFbd51YfkJ-c_crz%3D%3Dyfv8Ny8sOuPY8LZSv2aptA%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Emil S at Aug 24, 2013 at 6:11 pm
    I'm a big fan of RSpec, and I use it all the time. But I think Cucumber
    wins hands down in generating readable test outputs which can be important
    in many scenarios. Let me explain one such scenario which I faced in one of
    my projects.

    I was working on a Rails API app which would serve as the backend for a
    JS/native client running on platforms unknown to me. The API client was
    developed by a remote team separately. The remote developers would write
    client code to consume the APIs looking at an API documentation which would
    ideally describe the requests and all the possible responses from the APIs
    along with examples. The documentation would reflect the latest changes and
    it should be possible to obtain the documentation for every commit. The
    documentation would also ideally show the health of the APIs, so the client
    developers would know, for any given commit, which of the APIs work as
    expected ( mainly because I didn't want to answer questions like "Does the
    user listing API work, because I'm always getting a 403 status?" ) , If the
    API doc is green, it means it should work for a correct request. I used
    Cucumber to write integration tests and also for all the above
    requirements, and it worked well for me.

    Here's an example of the documentation cucumber would create for my user
    sign up API:

    Feature: Sign Up

         Background:
           Given I send and accept JSON

         Scenario: Passwords do not match
           When I send a POST request to "/api/users" with the following:
           """
           {
             "user" : {
               "first_name": "Kobe",
               "last_name": "Bryant",
               "email": "kobe@gmail.com",
               "password": "kobe1234",
               "password_confirmation": "kobe12345"
             }
           }
           """
           Then the response status should be "422"
           And the JSON response should be:
           """
           {"errors" : ["Password confirmation doesn't match Password"]}
           """

    RSpec can test this scenario alright, and it would be very much readable
    for any Ruby programmer. But I can't imagine a way to produce such a
    readable output with RSpec which could be read by a non Ruby developer, in
    my case a client side dev who may not be too interested in opening a ruby
    file to understand the API. But with cucumber, you are forced to think of a
    scenario as a sequence of steps, which really helped me in my case. My only
    problem with cucumber was writing regexes. But that's a small threshold to
    cross (I created some vim snippets to help me with the common regex
    templates) and it's not going to be one of your 99 problems.

    Cucumber worked amazingly well for me, but I may not use it all the time. I
    can't think of a reason why I shouldn't use it for every project, though.
    Laziness probably.


    On 24 August 2013 12:23, Ilya Igonkin wrote:



    On Sat, Aug 24, 2013 at 2:58 AM, Rekha Benada wrote:

    Rspec is a popular framework for unit testing and Cucumber is used for
    integration testing and behavior driven development
    It's pretty strange to hear since RSpec description is "BDD for Ruby".
    More than that, recent versions of RSpec for Rails (v2.12.0 or greater)
    support feature specs for integration testing whose syntax is very similar
    to Cucumber features. For more information see:
    http://www.andylindeman.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html

    Unit tests with rspec confirm that small, discrete portion continue
    working as developers add features.
    Integration tests built with cucumber determine wether the application's
    features work as expected,testing the application from user point of view.

    Thanks
    On Thursday, August 22, 2013 2:29:04 PM UTC-7, Jason Hsu, Android
    developer wrote:
    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact
    that it's in plain English, and this is an asset for communicating with
    clients or other people who aren't Rubyists. Migrating to Cucumber sounds
    like a good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well,
    yet still prefer RSpec? If so, why?
    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/38f9f99b-2dd0-46ae-9d79-bf20088a390d%40googlegroups.com
    .

    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/CAFp%3DAzPE4ytFbd51YfkJ-c_crz%3D%3Dyfv8Ny8sOuPY8LZSv2aptA%40mail.gmail.com
    .

    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAJ%3Dox-DrDYBYD7X6cu0k4PLSOm5rNYqavTVSQ2aiPpSf4_eLsQ%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andreo at Sep 7, 2013 at 10:24 pm
    Hi Emil,

    Can you show me that example in cucumber but written in Rspec I been trying
    to solve that problem and dont seem to be able to send the parameters in
    json to the page using rspec + capybara.

    all the best,

    Andre

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e47a549d-861e-47e3-838f-3aecf9785398%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Emil S at Sep 8, 2013 at 5:41 am
    Andre, what you need is Rack::Test, not capybara.

    On 8 September 2013 03:54, wrote:

    Hi Emil,

    Can you show me that example in cucumber but written in Rspec I been
    trying to solve that problem and dont seem to be able to send the
    parameters in json to the page using rspec + capybara.

    all the best,

    Andre

    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/e47a549d-861e-47e3-838f-3aecf9785398%40googlegroups.com
    .

    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAJ%3Dox-D4Hzp5yHMtUMZgJogNFc2%2BEd7HGxnTW1d46JHNTyWqXQ%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamara Temple at Sep 8, 2013 at 6:13 pm

    On Sep 8, 2013, at 12:41 AM, Emil S wrote:

    Andre, what you need is Rack::Test, not capybara.
    Not sure what you mean here. Capy uses Rack::Test by default: https://github.com/jnicklas/capybara#selecting-the-driver


    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9188AA0D-6A4F-4753-89F3-DD94A6C5AD6C%40gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Emil S at Sep 8, 2013 at 7:37 pm
    I meant to say simply use Rack::Test to make the requests while testing,
    Capybara isn't useful for interacting with an API directly.

    On 8 September 2013 23:43, Tamara Temple wrote:

    On Sep 8, 2013, at 12:41 AM, Emil S wrote:

    Andre, what you need is Rack::Test, not capybara.
    Not sure what you mean here. Capy uses Rack::Test by default:
    https://github.com/jnicklas/capybara#selecting-the-driver


    --
    You received this message because you are subscribed to the Google Groups
    "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/rubyonrails-talk/9188AA0D-6A4F-4753-89F3-DD94A6C5AD6C%40gmail.com
    .
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAJ%3Dox-BYLBNvVCC9u1wVabzFRc2QJws09YYDmtXB6EiKYRynBw%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lee Smith at Aug 27, 2013 at 9:42 pm
    My personal experience, of course, but the only time I'll ever write
    Cucumber features is if plain-english acceptance tests are a requirement.
      Otherwise (95% of the time), I'm quite happy with the RSpec/Capybara
    combo. The overhead of having to wire together plain-english to regular
    expressions just doesn't pay off in the end for normal acceptance testing.

    On Thursday, August 22, 2013 4:29:04 PM UTC-5, Jason Hsu, Android developer
    wrote:
    So far, I've been using RSpec for testing my Rails apps simply because
    that's what railstutorial.org emphasizes.

    However, I am in the process of trying out Cucumber. I like the fact that
    it's in plain English, and this is an asset for communicating with clients
    or other people who aren't Rubyists. Migrating to Cucumber sounds like a
    good idea.

    I'm curious about what you prefer. Do any of you know Cucumber well, yet
    still prefer RSpec? If so, why?
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9c7a0f68-1361-4503-bbdd-6f8cfdd2a6f7%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedAug 22, '13 at 9:29p
activeSep 8, '13 at 7:37p
posts13
users8
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase