[rspec-users] beginner questions: parametrize tests and disable tests (skippy?)

36 views
Skip to first unread message

nathanvda

unread,
Jul 26, 2010, 9:52:53 AM7/26/10
to rspec...@rubyforge.org
Hi there,

i have two very specific questions. I am writing an application to
send sms-es. Now i would like to be able, somehow, to disable the part
of my tests that actually sends the sms-es.
My code is tested, but to actually test sending the sms-es, i need to
test the configuration. So it is needed to test that too, but not as
frequently. E.g. our cruisecontrol would need to do it only once per
day or per week, but not every time somebody checks in.

For test::unit there exists a solution: http://github.com/jm/skippy
Is there a similar solution for Rspec?
Or how do you guys solve this?

Secondly i have a small look-up table, and i want to check that my
function gives the correct result.

I would like something like the commented part, because if one lookup-
translation would fail, we get an appropriate message:

# STATUS_EXPECTED_TRANSLATIONS.each |tr| do
# it "should translate #tr[0]} to success" do
# result = translate_status(tr[0])
# result.should == tr[1]
# end
# end

it "should translate received statuses" do
STATUS_EXPECTED_TRANSLATIONS.each do |tr|
controller.send('translate_status_to_envelope_status',
tr[0]).should == tr[1]
end
end

Is that possible? Or what is the advised way to handle/test something
like that?

_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Wincent Colaiuta

unread,
Jul 26, 2010, 11:37:32 AM7/26/10
to rspec-users
El 26/07/2010, a las 15:52, nathanvda escribió:

> For test::unit there exists a solution: http://github.com/jm/skippy
> Is there a similar solution for Rspec?
> Or how do you guys solve this?

The way to do the "Skippy" thing under RSpec 2 will be filtering:

http://blog.davidchelimsky.net/2010/06/14/filtering-examples-in-rspec-2/

> Secondly i have a small look-up table, and i want to check that my
> function gives the correct result.
>
> I would like something like the commented part, because if one lookup-
> translation would fail, we get an appropriate message:
>
> # STATUS_EXPECTED_TRANSLATIONS.each |tr| do
> # it "should translate #tr[0]} to success" do
> # result = translate_status(tr[0])
> # result.should == tr[1]
> # end
> # end
>
> it "should translate received statuses" do
> STATUS_EXPECTED_TRANSLATIONS.each do |tr|
> controller.send('translate_status_to_envelope_status',
> tr[0]).should == tr[1]
> end
> end
>
> Is that possible? Or what is the advised way to handle/test something
> like that?

Yes, it's possible, but generating examples is a technique to be used sparingly, only when it makes sense to do so.

Generally, the trade off between "explicit" and "DRY" is different in specs than it is in code. In specs we value explicitness and simplicity above DRYness (the specs have to be bug free, they have to be readable, they should be a document -- ie. a specification -- of the behavior of the code, and perhaps most importantly of all, you want to be able to click on a failing spec's file and line number and be taken straight to it and know which spec failed without any ambiguity) whereas in code DRYness is given a much higher value.

So I don't know how many entires you have in your STATUS_EXPECTED_TRANSLATIONS, but if the number is small enough, I'd suggest that you just list the translations explicitly, repeating the "it" block for each translation.

Cheers,
Wincent

nathanvda

unread,
Jul 27, 2010, 5:05:06 AM7/27/10
to rspec...@rubyforge.org
>
> The way to do the "Skippy" thing under RSpec 2 will be filtering:
>
> http://blog.davidchelimsky.net/2010/06/14/filtering-examples-in-rspec-2/

Awesome! Just what i need :)


>
> Generally, the trade off between "explicit" and "DRY" is different in specs than it is in code. In specs we value explicitness and simplicity above DRYness (the specs have to be bug free, they have to be readable, they should be a document -- ie. a specification -- of the behavior of the code, and perhaps most importantly of all, you want to be able to click on a failing spec's file and line number and be taken straight to it and know which spec failed without any ambiguity) whereas in code DRYness is given a much higher value.
>
> So I don't know how many entires you have in your STATUS_EXPECTED_TRANSLATIONS, but if the number is small enough, I'd suggest that you just list the translations explicitly, repeating the "it" block for each translation.
>

Thank you for your advice! It makes sense to me, and the list of
options is indeed limited ;)

Reply all
Reply to author
Forward
0 new messages