[EMAIL PROTECTED] wrote: > 1. To test the code, you need to change it. > 2. Before changing the code, you should test it. > > How do we resolve these two opposites ? We change as little as > possible.
*snip* > A lot of my more recent thoughts about testing and development have > come from a wonderful book <plug mode='on'>Working Effectively with > Legacy Code by Michael Feathers"</plug> The most memorable line from > that book (that I've read so far - I'm still in the first 25%) can be > paraphrased - *clicky* on my wishlist. > I would also posit that no matter how bad a codebase, there is > _always_ sonething you can do without causing damage - in the 800 > line subroutine, take a chunk, place it in a function in a namespace, > and test that in isolation. Take another chunk, repeat till you have > a 500 line subroutine with some semi-meaningful calls to nicely > tested functions. And so on. I've thought things like that in the past, innocent refactorings, and broke shit. Especially since they have to be done by hand (where's my refactoring browser!?) At absolute minimum, with a big ball of mud, you can do dumb high level "exact input/output" tests of the sort which would normally be frowned upon. For example, got a big web app? Write a script to do something with it and save the resulting HTML. [2] Then test that doing the same thing again produces exactly that HTML. [1] These tests are fragile and ugly and don't provide good coverage but they can warn you if something changed. Then you can refactor the mud into something more testable with a bit of a safety net. [1] Cleverness is necessary for dynamic content, such as a timestamp on the page. Someone at OSCON mentioned a testing module which could force time to stand still for testing but I can't find it. [2] Or use something like Selenium.
