Re: Using refactoring to make code more testable Re: [refactoring] Using refactoring to make code more testable

Adam Sroka <[email protected]>
Newsgroups gmane.comp.programming.refactoring
Message-ID <[email protected]>
On Sun, Oct 11, 2009 at 12:48 PM, Richard <[email protected]> wrote:
>
>
>
> In article <1932321348-1255280632-cardhu_decombobulator_blackberry.rim.net-1918218162-@bda056.bisx.prod.on.blackberry>,
> [email protected], [email protected] writes:
>
> > My main task is to get the code covered. [...]
>
> To what end?
>
> The three rules of programming apply:
>
> 1. Don't do it.
> 2. Don't do it again.
> 3. When all else fails, break rule 1.
>

I don't know where that comes from. It's cute, but makes no practical
sense to me.

> In this context:
>
> Don't write tests just for the sake of writing tests, particularly on
> legacy code. The changes you need to make to legacy code in order to
> make it testable can just as likely introduce defects as they will
> make the code testable.
>

No one writes tests for the sake of writing tests. We write tests so
that we know if it works. If we don't need to know if it works then we
don't need "it" either.

It may or may not be true that breaking apart seams can introduce
defects. At least, some seams are easier than others and Feathers'
book does a decent job characterizing the difference.

Sometimes you can avoid seams more or less by writing integration
level tests. End-to-end tests don't need any seams, but they are slow.
The trick is to write just enough of these kinds of tests to
characterize the behavior that you want and then use them for
regression while replacing them with unit tests.

> If you have defects to fix in that legacy code, then do traditional
> debugging to find the location of the fault and then do a minimal
> amount of decoupling around the fault so you can write a failing test,
> fix the fault and get a passing test. Leave the rest alone.
>

I would like to see a situation where traditional debugging is more
efficient than covering something with tests. In over twenty years of
programming, only eight of which I've been doing TDD, I can't recall a
time when I debugged something once and didn't have to debug it again.
The same is true for testing, but testing is a hell of a lot easier to
automate.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.