On Jun 28, 2008, at 5:32 AM, David Chelimsky wrote:
I'm beginning to regret the validity example, because it is somewhat
structural as well. The behaviour is not whether it's valid or not,
but rather whether you can save it or not. So scratch the example I
gave earlier and think about this:
describe Project do
describe "when trying to save" do
it "should complain if it has no owner" do
lambda do
Project.new(:owner => nil).save!
end.should raise_error(ActiveRecord::RecordInvalid)
end
end
end
(Zach Dennis - this nesting structure should make you happy :) )
That make a bit more sense?
Absolutely!
One key aspect of BDD is working Outside-In. I try to start with a
story and to drive things down from the view to the model (in
Rails). So maybe my story is that as an owner I can edit my
projects, but not other people's projects. This is going to
naturally lead me towards examples that will implicitly cover the
fact that an owner can more than 0 projects without actually
specifying that directly.
Trying to wrap my head around how to go about BDD has been difficult
and I think I now understand why. Many of the examples I've seen for
RSpec have used things like "should be valid" when that doesn't
actually describe behavior at all. The first RSpec generated Rails
specs that I used had plenty of this but that seems to be more about
implementation than behavior, so I've had trouble understanding how to
really describe behavior.
Little by little I'm getting it, but I unfortunately don't feel like I
have time to go BDD cold turkey. I still do some code first and then
spec, but I understand the benefits of BDD and I'm sure I'll get to
that point eventually.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
