Jordan Fowler wrote:
> I enjoyed your write-up and agreed with a lot of what you said. It's
> about time for folks to check out some other testing frameworks, instead
> of just "going with the masses." Most people would probably agree, RSpec
> can really weigh a project down and become overwhelming when there are
> large requirement changes.
I didn't go that far. Tests should _help_ requirement changes! What hurts is
endlessly rambling tests that don't isolate their tested details.
You can get the bad kind of test (copious experience here) by writing long
complex test cases that walk your objects thru many states. Do people do that
with RSpec? Do they write rambling "specs"? Or does RSpec make nesting
contexts,
setups, and "what-ifs" so easy that it generates rambling tests out of specs
that look well-factored?
Note that's what test/spec means for us - only this:
context 'general' do
setup{ general }
specify{ something general }
specify{ another general thing }
context 'specific' do
setup{ specific }
specify{ test general and specific together }
specify{ test specific and general together! }
end
end
The alternative in TestCase was only either a setup() that builds both
'general'
and 'specific', when two cases don't need it, or duplicating 'specific' into
two
test cases, or merging the 'specific' setup into a global 'assemble_specific'
method yadda yadda yadda. Nesting the contexts lets them share their setups, so
the contexts are much easier to mix and match.
(Also those setups conflict with our fixtures loader - more about that if
anyone
has this problem!)
So do those kinds of tests make coupling the 'general' and 'specific' things
too
easy?
--
Phlip
--~--~---------~--~----~------------~-------~--~----~
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
-~----------~----~----~----~------~----~------~--~---
