On Thu, Apr 16, 2009 at 1:15 PM, svoop <[email protected]> wrote: >> 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 > > This would work: > > article = Article.new(:fetched => nil) > article.fetched # => nil (default overridden) > article.should have(1).error_on(:fetched) # => GREEN 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. Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
