On Mon, Nov 03, 2003 at 09:32:28PM -0600, Michael Carman wrote: > On 11/3/2003 12:20 PM, Tim Bunce wrote: > > On Tue, Oct 28, 2003 at 05:33:09PM +0000, [EMAIL PROTECTED] wrote: > >> > >> Right now, if your cover_db holds data for a dozen files, but you test them > >> one at a time, you have to read and write *all* the coverage data (as well > >> as have the RAM to hold it). That's a lot of unnecessary work and wasted > >> memory. > > > > Generally there'll be a set of driving scripts (eg test scripts) and a bunch > > of modules being used by the driving script. Coverage for most of the module > > source files would be generated by most of the tests. Or am I missing > > something (I've not looked closely, still). > > I probably just have a different perspective. Right now, I'm writing an > application that's broken into a dozen or so modules. The test suite shares a > common cover_db, and reading and rewriting the data for the modules I'm not > currently testing takes extra time. > > To some degree, my position is just based on good software design -- don't use a > bunch of memory or do a bunch of work if you don't need to. It might not matter > for small dbs, but it doesn't scale.
I agree. I still at the "looking for low hanging fruit" stage. Tim.
