El 7/9/2007, a las 5:36, Jay Levitt escribió: >> There's a very useful guideline in TDD that says "test YOUR code, not >> everyone elses." The validation library we're testing here is >> ActiveRecord's. It's already tested (we hope!). > > Right... and I'm not testing that ActiveRecord's validation works. > I'm > testing that my model works as I expect it to work. > > For instance, in your example, you just verify that you call > validates_presence_of with fieldname :digits. You're not verifying > that > that's the right thing to do, or that it behaves the way you expect > it to. > > Also, I think this conflicts with "test behavior, not implementation". > All I care about is the behavior of the model; I don't care if it > calls > validates_presence_of, or if it calls acts_as_phone_number.
Very true that you shouldn't be testing ActiveRecord's validation (Rails' own unit tests are there for that). But if you want to do truly *driven* BDD then you will have to test something; in other words, *before* you go ahead and add this line to your model: validates_presence_of :foo You need to write a failing spec for it first. Otherwise, why would you write it? Doing BDD in its purest form you shouldn't be writing *any* line of code without your specs driving it. This means the familiar "write failing spec, write code, confirm working spec" cycle. So the question is, what is the best kind of spec to write to *drive* the writing of your "validates_presence_of" lines? For some validations it's quite easy. For others it is less straightforward. There are probably multiple valid (or valid-ish) answers, but it's sometimes difficult to know which one is best. Cheers, Wincent _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
