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?
El 26/07/2010, a las 15:52, nathanvda
escribió:
For test::unit there exists a solution: GitHub - jm/skippy: A little Test::Unit/minitest extension to only run long running (or whatever) tests when given an environment variable.
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/
end
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
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 