[rspec-users] beginner questions: parametrize tests and disable tests (skippy?)
win at wincent.com
Mon Jul 26 11:37:32 EDT 2010
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:
> 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} to success" do
> # result = translate_status(tr)
> # result.should == tr
> # end
> # end
> it "should translate received statuses" do
> STATUS_EXPECTED_TRANSLATIONS.each do |tr|
> tr).should == tr
> 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.
More information about the rspec-users