On 11 Feb 2010, at 04:46, Alex Satrapa wrote:
> I''m sure this has been covered before, but after some time all
I''ve
> been able to find on the intarwebs are references to the use of code
> coverage tests to identify code that is not used by any current tests.
>
> I guess the assumption is that you''ve specced your application
> completely, and any code left over doesn''t contribute to any of
the
> specified functionality.
>
> However at some point in the future, I may decide to remove a
> feature. Perhaps my excision is not complete, and I leave a few
> specs in that relate to that code, but don''t immediately appear to
> be related to the feature I wished to remove. So I''m left with
100%
> code coverage, due to a few specs hanging around which cover
> functions that are no longer actually required.
>
> Have you run across this situation? What do you do to prevent the
> "zombie" code hanging around and gnawing on your brain?
Cucumber.
If I remove a feature from the application, I have to remove a
scenario or two from the cukes. I can use rcov to tell me the code
that''s covered by those scenarios before I remove them, which gives me
an indicator as to what *might* need to be removed. If I''ve been good
and driven all of the application behaviour using Cucumber, I can then
run rcov after the scenarios are gone, and I should see that any
unused code is not covered at all. I can then either try to figure out
what specs cover that code, or just remove the unused code and let the
specs tell me themselves.
Pair programming is also an excellent weapon against slop, as you''ll
have at least double the confidence that the code you''re looking at is
indeed unused, and double the courage to delete it.
cheers,
Matt
http://mattwynne.net
+447974 430184