[rspec-users] Role of stories vs specs, revisited
dchelimsky at gmail.com
Fri Jan 11 16:48:20 EST 2008
On Jan 11, 2008 3:43 PM, Pat Maddox <pergesu at gmail.com> wrote:
> I'm going to hijack this a bit :)
> On Jan 11, 2008 1:25 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > But the target of stories are system level descriptions of behaviour.
> > This will inevitably appear to have some overlap with the specs for
> > the outermost layers of the system. But when you start refactoring,
> > those object specifications are going to change - the system specs
> > (stories) should NOT. At least not as a result of refactoring.
> In the first thread I linked to, I said something along the lines of
> "maybe stories are better for refactoring, since you don't have to
> change them."
Keep in mind that in Java, where I think refactoring really grew in
its formality as part of the process, the tools make the changes in
your tests too. When you change a method signature the tool changes it
everywhere. I don't recall, ever, seeing anyone complaining about
having to change tests when refactoring in java. So this is a price we
pay for the benefits of early adoption in our language of choice.
> Examples, on the other hand, sometimes have to be
> changed when refactoring, particularly if you use mocks.
> However, stories are probably too slow for refactoring, and some of
> the problems with refactoring with examples are simply a matter of
> lacking tool support, which should eventually be fixed.
Right - missed this on the first read - that's what I'm talking about
in the paragraph above.
> I don't have any problem with that. I do things that way, and I get
> my work done just fine. However, I'm having a tough time clarifying
> my position when talking to people who believe that unit tests should
> not have to change when refactoring either. I don't think they're
> wrong, actually.
I do. If you read the refactoring book, every refactoring has a "now
change all the clients" step - tests are clients that have to be
changed. It's just part of the deal.
The thing is that, ideally, you don't want to have to make changes to
the tests for object A when you're refactoring B.
> It's just a different approach and I'd like to know
> how to bridge that communication gap better.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users