Spec:
it do
article = Article.new(valid_attributes.except(:fetched))
article.should have(1).error_on(:fetched)
end
Like this the spec will always fail because although fetched is excepted
from
the hash returned by valid_attributes, it still gets set to false due to
the
default value. Therefore no error and therefore the spec booms.
A solution would be to use this instead:
article = Article.new(valid_attributes.with(:fetched => nil))
But that would block refactoring if many attributes are tested for
errors.
Ideas?
Spec:
it do
article = Article.new(valid_attributes.except(:fetched))
article.should have(1).error_on(:fetched)
end
Like this the spec will always fail because although fetched is excepted from
the hash returned by valid_attributes, it still gets set to false due to the
default value. Therefore no error and therefore the spec booms.
The two examples you gave are very different semantically. The first
follows “no value was provided, so use the default.” The second is
“an invalid value was provided.”
A solution would be to use this instead:
article = Article.new(valid_attributes.with(:fetched => nil))
But that would block refactoring if many attributes are tested for errors.
Ideas?
What do you mean by it blocks refactorings? This isn’t any different
from the first example, with the exception that you provide a value
instead of letting the default kick in…
What do you mean by it blocks refactorings? This isn’t any different
from the first example, with the exception that you provide a value
instead of letting the default kick in…
article = Article.new
article.fetched # => false (due to default)
article = Article.new(valid_attributes.except(:fetched))
article.fetched # => false (again due to default)
article.should have(1).error_on(:fetched) # => RED LIGHT
The problem is that Article.new doesn’t return an object where all
attributes
are nil and therefore the attributes passed must set defaultet
attributes
explicitly to nil for it to override the defaults.
I wonder how other people treat this case.
Okay I must be dense because I’m not sure what you mean by it gets in
the way of refactoring.
And you’re right about how it behaves…that’s exactly how default
attrs work. If you want to test that your model doesn’t allow invalid
data, you have to explicitly give it invalid data.
Could you rephrase the problem perhaps? Or wait for someone smarter
to come along.
Okay I must be dense because I’m not sure what you mean by it gets in
the way of refactoring.
Actually, scratch that, because…
And you’re right about how it behaves…that’s exactly how default
attrs work. If you want to test that your model doesn’t allow invalid
data, you have to explicitly give it invalid data.
Using .with instead of .except does the trick just fine and does just
that, set
the model explicitly to invalid data.
Using .with instead of .except does the trick just fine and does just that, set
the model explicitly to invalid data.
gah, I totally get it now! Wasn’t noticing that in one case you were
passing in a full attributes hash (valid_attributes) and in the second
you were only setting one value. Makes sense to me now. Glad you
figured it out
My question is, why bother? Unless I’m missing something, testing for
the existence of an error that your code will never provide sounds
backwards. Instead test that you DON’T get an error when the required
value isn’t explicitly supplied, to confirm that the default works.
(Although, really, the “pure” time to do that would’ve been before
writing the migration, to get the red-to-green verification. That may
be excessively pedantic though.)
