[rspec-users] Should deleting code require failing specs?
sfeley at gmail.com
Thu Jul 16 11:35:52 EDT 2009
On Wed, Jul 15, 2009 at 6:03 PM, Adam Anderson<adamandersonis at gmail.com> wrote:
> Sometimes when features are asked to be removed it doesn't make sense to
> specify that they shouldn't be there. It seems to me that removing something
> from a tested app should not entail writing a failing spec for that change.
> I'm curious if people have different opinions or insights on this.
I'd think about the following:
* Is the *absence* of the feature a new functional requirement?
* Would the existence of the feature after it's not supposed to be
there any more have an impact on users or other stakeholders?
* Is removing the feature likely to be problematic for any reason?
* Is it at all possible that the way you deploy code could cause the
feature -- or part of the feature -- to be there when it shouldn't be?
(This is usually a "yes." Even if you're doing an online app with
cookie-cutter Git and Capistrano deployment, someone could forget to
merge the right branch, or leave "drop table" migrations dangling, or
You want to spec things that matter. If it *matters* that something
goes away in a predictable manner, and there's any possibility that it
might not, it's probably worthwhile to write specs for it. If the
reason you're removing it is just because no one's using it and no one
cares... *shrug* Then you're not obliged to care more than anybody
else does. >8->
Steve Eley (sfeley at gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
More information about the rspec-users