2 ms·
I'd also like to plug my own rspec extensions, Saki: https://github.com/ludicast/saki https://github.com/ludicast/saki It lets you write your specs with "smar
by ludicast 16y ago
I'd also like to plug my own rspec extensions, Saki:
https://github.com/ludicast/saki https://github.com/ludicast/saki
It lets you write your specs with "smart contexts" so you can do stuff like:
with_existing :user do
that_has_an :article do
that_has_a :comment do
or
with_existing :user do
on_visiting edit_user_path do
it { should let_me_edit(@user) }
end
end
I'm obviously biased, but I think this sort of testing kicks ass. I initially wrote them as extensions to Steak, but then ripped them out to use with vanilla rspec.
- sleight42 16y agoThe only problem that I see with this is the same that I see with vanilla RSpec or shoulda: state is accumulated through nested blocks. This is why I tend to prefer the Given-When-Then style with reusable "macros" (class methods) that provide niceties such as "given_a :user", "when_i_visit root_path", etc. Assuming that you are writing automated acceptance test, any test of more than trivial length would then be nested several levels deep.
- ludicast 16y agoThat's a reasonable argument but doesn't bother me because 1) I don't like the given/when/then syntax anymore (a personal thing, but I do see the advantages (Uncle Bob has a great article about it)) 2) I don't mind the nesting as long as each context is making explicit what it does. Of course it's a "different strokes" thing. I could see this not fitting in with everybody's style but for me it has DRYed up the parts of a test that should be DRY (imho).