On Wed, Jul 15, 2009 at 6:03 PM, Adam Anderson<adamanderso...@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 whatever.) 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-> -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
