On 10/19/07, Scott Taylor <[EMAIL PROTECTED]> wrote: > Following up on the last idea: One thing that I don't think is yet > widely understood is that there is no such thing as a "unit" or > "integration" test - test happen on a continuum (the classification > of a test is not a black and white sort of thing). Your "assumption > tests" are basically model-level integration tests, which are not as > fine grained as the normal spec (which would mock/stub out AR::Base, > associations, validations (with load...), etc).
While vocabulary is important, particularly shared vocab, it's even more important not to get too hung up on it. I've read plenty of sources that say a unit test only touches one class, and if you're interacting with more than one class then it's an integration test. That's a silly distinction to make - as you point out, there's no clear definition of what a unit test is. You should be comfortable working at the appropriate level of granularity, whether it's writing a spec for one small method in a given context, or for a couple collaborating objects. Also, I probably wouldn't go up to Kent Beck and say, "your book was nice and all, but I wish you would have admitted that you were writing INTEGRATION tests instead of unit tests." :) I think it becomes too easy to use process or arbitrary constraints as a crutch, instead of simple careful thought. If you find yourself doing strange or painful things in order to make them fit some definition, then you're doing yourself a disservice and need to step back and evaluate your goals. Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
