From: Dave Fayram Date: 2005-08-26T04:01:36+09:00 Subject: Re: The Chainsaw Infanticide Logger Manuever On Aug 24, 2005, at 10:55 AM, Jeff Wood wrote: > Ok, my set of tests for my application would include asserting that if > a given piece of functionality is going to cause a log message to > occur, that I validate the residual log files do contain the log > entries I expected as I expected them to be formatted. If they don't > then the application/library doesn't meet it's spec and/or > requirements. It's a bug and it needs to be resolved. > > So, you would then have a front-row seat if something was affecting > the logger output. At some point--and that point approaches us very quickly on anything larger than a trivial project--we have to trust that our libraries work as documented and that others won't deliberately mess our environment up. Extension of a class to have a to_whatever is one thing, changing behavior that was there before is another. So, I'm not sure that testing this kind of thing is even reasonable. It might be nice to have, but part of the point of TDD is to keep you on track and developing at a consistent pace. If I stop to check every method I might use, I'm going to get sidetracked far too quickly in a language like Ruby I think the moral of the story is that Logger needs a meta channel which records the state of the logger itself. I've used loggers that have such a feature and it's surprisingly useful. > And no, I don't believe there is any difference between building a > library and building an application ... it's all code that needs to be > tested and made sure it functions completely as designed. > > I hope that answers you sufficiently. > > j. > > > On 8/24/05, Bill Kelly wrote: > >> Jeff, >> >> From: "Jeff Wood" >> >> >>> The truely iterative & testing-complete way to build software is to >>> design and implement your tests before you write your code. When >>> all >>> of your tests pass, you're done... >>> >>> ... If you built your system like that, you should have tests for >>> each >>> and every action on your classes ... and the first time somebody >>> elses >>> modifications has an affect on your functionality and expected >>> output, >>> you should know about it. >>> >> >> I appreciate the well-meaning nature of your replies, but I've >> been programming for 24 years and doing TDD semi-consistently >> for the last 5. >> >> Again, I'd ask to see what sort of test you'd propose that would >> catch the problem I described. (My post, the one you quoted, was >> about CGI, not the Logger.) >> >> >>> To answer "how/why would you test this"... you should have tests in >>> place for your logging functionality. The second something doesn't >>> come out right, you know that something is marring the system. >>> Debugging starts by walking the source of the packages you are using >>> and watching for references to the modified functionality... It's >>> not >>> that hard to track down. >>> >> >> Thanks for the tip. =D >> >> >> I also would ask again, Do you not consider libraries and >> applications >> different, where Ruby's beloved Openness is concerned? >> >> >> Regards, >> >> Bill >> >> >> >> >> > > > -- > "So long, and thanks for all the fish" > > Jeff Wood > > -- Dave Fayram Software Developer