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/