[rspec-users] testing behaviour or testing code?
drichards at showcase60.com
Fri Sep 7 10:52:38 EDT 2007
On Sep 7, 2007, at 8:24 AM, Wincent Colaiuta wrote:
> El 7/9/2007, a las 5:36, Jay Levitt escribió:
>>> There's a very useful guideline in TDD that says "test YOUR code,
>>> 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.
>> 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'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
>> All I care about is the behavior of the model; I don't care if it
>> 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.
I've kind of adopted this plain-vanilla approach:
You'll see I'm a little fat, especially with my polymorphic
association. Maybe they can be improved, but it's been the right
balance of testing before I write code for me--I gain confidence and
momentum, and my later iterations are constrained enough to keep me
from stepping out of bounds. I'm sure my ideas will evolve over time.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users