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": "k...@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 <osd...@gmail.com> wrote:
>
>
>
> On Sat, Aug 24, 2013 at 2:58 AM, Rekha Benada <rekha.ben...@gmail.com>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+unsubscr...@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+unsubscr...@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+unsubscr...@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.
