[DUnit-interest] [Fwd: [Fwd: Leak Testing: Second iteration]]

[Peter M. <mc...@me...>]

Hi Team

A revised set of files has been dispatched to Jud's private mailbox which I'm sure he will acknowledged when time permits.
The accompanying text is reproduced here, minus the .zip.

If anyone else needs to review or try the latest changes then just provide an email address that doesn't bounce .zips.
I had dispatched a .png several days ago to prompt some comment but it seems to have been gobbled by the system on size.

Rgds
Peter


Another iteration in the DUnit leak testing capability is available for 
review and testing. :-)
In essence, "memory imbalance" is now reported separately for Setup, 
TestProc and TearDown. This was the next step design goal, and 
significantly eases the burden as expressed in Kristofer's lament.
See [DUnit-interest] Re: Follow up to Notes about DUnit 9.2.x of (1:23 
Jan 11th UTC)
Additional unit tests have been created to help validate the new DUnit code.

Advice was sought from Pierre le Riche regarding FastMM's smallblock 
memory allocation predictability. In Multi threaded environments there 
is no guarantee of a known memory block size being allocated. 
Consequently the procedure AddKnownLeakSize has been removed.
Parallel functionality is still available from the property 
AllowedLeakSize and takes an observed size. To cater for the occasional 
step up in smallblock size allocation, as experienced (only in D2006) 
more than one leak size can be enabled. The maximum number is currently 
set at 4 sizes. I stress occasional (as in infrequent) too.

All field parameters are now prefixed with capital F, in the main files 
I have touched anyway.
Two of CodeHealer's astute recommendations have been addressed.
Several destructors have been tightened.
The BoolToStr issue and D5 has not been addressed.
There are many instances where "const" should precede parameters in 
procedure/function calls but I am leaving them untouched just now. I 
don't want to further confuse the issue of adding functionality and 
doing a code tidy up.
Similarly, "refactoring" has not been attempted, yet.

Coding styles.
I find of the easiest Delphi code to read deviates from the "Borland" 
style in that property read./writes are often vertically aligned. Quite 
a lot of existing DUnit code already has some aligned look about it. 
Similarly function/procedure calls whose line lengths exceed the nominal 
80 char page width and contain multiple parameters are much easier to 
"grasp in a glance" when the parameters are vertically aligned. As you 
may have noticed by my additions to the code. However, not wishing to 
offend the original DUnit author's works and preferences and the group's 
sensitivities I am unconcerned if you have good reason to desire a more 
"standard" look. So feel please free to alter the works or send it back 
with guidelines.
Quite a lot of work has gone into getting the changes done and verified, 
so it's entirely possible I have reversed some of the style changes, for 
the purpose of adding visual clarity (for me). So please again don't 
take that as any kind of insistence at all.

Tested under D5, D7 and D2006.
The attached .zip contains just those files changed from those received 
on 29th Dec 05.

Although there are indications that specific debug reports from FastMM 
might be achievable, they would only be at the closure of the unit 
test.exe so hope you find the effect of these changes warrants acceptance.

Regards
Peter