[rspec-users] Dealing with dependent data
jim at saturnflyer.com
Fri Jun 27 19:58:11 EDT 2008
>>>> That post is fantastic. Thanks!
>>> Couldn't agree more with that post... For instance,
>>> restful_authentication now comes with specs, but, ehrm... See for
>>> yourself: http://pastie.org/222670
>> haha. I have no idea what's going on there.
> This is slightly OT.. but looking at those specs brings up one of my
> other pet peeves, and that is excluding the "should" from the
> specs. I have seen a lot of projects and developers that I respect
> highly not use the word "should" in there specs. I have accepted it
> as just one of those things that people disagree on, but I think
> there is a lot of value of having the "should". For one it makes
> removing the example easier when it becomes incorrect (meaning, the
> expected behaviour has changed.) I guess I just see the "should" as
> being a bigger part of BDD than some people.
> Am I the only one who thinks this or what are the arguments for not
> using 'should'?
I've been meaning to ask the list about this for a while now.
I don't always use "should", but I've been trying to come up with a
standard way to approach the Rails has_one, has_many, etc. as opposed
to methods on the object such as name, description etc.
What I mean is that I want to write specs so that I know if something
refers to an associated object or not, without resorting to writing
technically oriented specs that define implementation rather than
"project should have an owner" unfortunately doesn't let me know if
it's a method that returns a value, or a method that returns another
object. Does anyone have advice or experience in writing the specs to
provide that kind of information?
I hope this isn't too much of a thread hijack.
But to bring it back around, I totally agree with the article, and
it's particularly apropos for open source projects (assuming the
project owner wants new users to get involved in development)
More information about the rspec-users