Comments on: a testing dilemma http://silkandspinach.net/2007/03/31/a-testing-dilemma/ development, by example Mon, 19 Mar 2012 12:48:20 +0000 hourly 1 http://wordpress.com/ By: kevin http://silkandspinach.net/2007/03/31/a-testing-dilemma/#comment-227 Tue, 03 Apr 2007 21:30:51 +0000 http://silkandspinach.wordpress.com/2007/03/31/a-testing-dilemma/#comment-227 Agree with all you say about long methods, although I don’t think that’s the source of the problem in this case. Even if it were broken into twenty 10-line pieces, the lack of test coverage at that level (and the calling levels above) would still mean that the same accident could occur. Indeed, it could be argued that a flotilla of small classes and methods might serve to further obscure the importance of my tested method – and thus render the accident more likely to occur.

But just one test of that method – did we find the configuration files, for example – would kill my worry stone dead. The long method’s lack of testability is the real problem. Or the fact that I couldn’t quickly see a way to test it!

(BTW, I meant “geometric” coloquially, in the sense of “rising faster than linearly”. Apologies for the confusion…)

]]> By: hgs http://silkandspinach.net/2007/03/31/a-testing-dilemma/#comment-226 Tue, 03 Apr 2007 11:22:47 +0000 http://silkandspinach.wordpress.com/2007/03/31/a-testing-dilemma/#comment-226 I think the problem with this refactoring is that it didn’t go far enough. Changing the structure by 1% won’t change how the future programmer thinks of it, and (s)he will probably bring the code back in to “save on a method call”. I think the problem is that the method you started with is 200 lines long. That is not insignificant for a whole program: I think the Ruby-Talk <-> comp.lang.ruby gateway was that long in total when it was created. Printed out, it would be over 3 pages of 66-line paper. I used to think that the instructions to keep methods short (one screen long, so about 25 lines) were just silly: clearly written code can be much longer and still well-understood. I’m finding now that when I move code out of long methods I suddenly see new ways in which the new, short methods can fail, which never occurred to me when the code was “in context”. I think this is because the brain is so poor at managing logic, especially paths through code. That ties in with the short term memory limits of 7 “chunks”. [Or maybe I'm just saving face here, and should have the courage to admit to being thick :-)] If code is about communicating with other humans, then some of them will be less bright than you, so simplifying the method by creating more methods is probably good.
Your points about testing unused methods are interesting, and I don’t see a way around that which allows refactoring to work. Your points about test coverage make sense, though I could not assert that the relationship is geometric.

]]>