>> The thing is that, ideally, you don't want to have to make changes to
>> the tests for object A when you're refactoring B.
>>
>> WDYT?
> Yeah, I buy that. Not everyone does though. Or at least not everyone
> feels that it's a particularly important goal.
I think the fear many of us classicists have is that if A uses B (and Bs
interface changes) then A will pass but it shouldn't. We also have to go around
updating all the mocks for tests that use B. With a state based approach we
wouldn't have to change any tests assuming we've fixed the outer methods
already. If we haven't then our tests will fail and tell us we need to.
I know, our integration tests should catch this. I'm curious what you guys mean
by "integration tests" in this case. For example, in a rails app are the
'integration tests' always or usually testing the full rails stack by sending
web requests and verifying against the response? I.e. simulating a user
interaction?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
