Should I be only having one file per model? What is the convention for
naming and creating specs when speccing out cross object behaviour?
Really appreciate your thoughts.
Also, can anybody recommend any good books or tutorials on Rspec?
Many thanks!
You don’t necessarily have to have one spec file per model. It’s a
pretty convenient convention though (and I just noticed for the first
time in my life that convenient and convention have the same root).
You can do whatever you want to keep your specs organized, but I’ve
found that I don’t often need to use multiple files to spec the same
class.
As for tutorials, I’d recommend watching the peepcode vids. They do a
great job of demonstrating the technical use of RSpec, though they’re
a bit light on the conceptual stuff. For some info on why BDD kicks
TDD’s butt, I would check out
What is the convention for naming and creating specs when speccing out cross object behaviour?
I missed this. For stuff like mixins, I’ll generally stick the module
definition under lib/ and have a corresponding spec under spec/lib.
Also I usually write the spec like
module NameableSpec
class Person
include Nameable
end
describe Nameable do
before(:each) do @person = Person.new @person.set_name “Pat M.”
end
it "should parse the first name" do
@person.first_name.should == "Pat"
end
it "should parse the last name" do
@person.last_name.should == "Maddox"
end
end
end
The reason that I do that is because in order to write a spec for this
module, I have to actually mix it into a class. I wrap the whole spec
in a module so that my test class name doesn’t clash with any existing
class names.
Another way to do it is to define the class dynamically before each
test:
describe Nameable do
before(:each) do
klass = Class.new { include Nameable } @person = klass.new @person.set_name “Pat M.”
end
it “should parse the first name” do @person.first_name.should == “Pat”
end
it “should parse the last name” do @person.last_name.should == “Maddox”
end
end
The upside to that is that you don’t have the ugly wrapper module.
The downside is that you can’t easily reuse the class between describe
blocks - you’d still want to have a wrapper module to avoid polluting
the namespace. I tend to prefer this dynamic class creation, because
it’s usually less code. I also end up with a bunch of little,
temporary helper classes that have only the behavior I want, rather
than a bigger test helper class with behavior to support multiple
specs.
I’m curious how other people handle this type of thing.
Pat
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.