RE: [Cppunit-devel] hierarchy sample bug...

[Townsend, G. <gto...@sh...>]

Just one thing I realized today about the solution below: dynamically
allocating the suite in the test case could be dangerous; at least given the
current environment on Win32. The issue is that there are multiple DLLs and
the application, all of which could be using different versions of the
run-time library. It may not be safe to call delete on memory allocated in a
different module. While it is in the same process space, the actual code in
the RTLs could be different, depending on how each module was linked. (ie.
static RTL vs DLL RTL vs multi or single threaded vs different versions of
compiler). I recently read about this all too common problem in Jeffrey
Richter's "Programming Applications for Microsoft Windows - Fourth Edition"
Given his expertise level, I would have to bet it's a real problem that
should be avoided. The bottom line is that memory allocated in a given
module should be freed in that same module. 

The basic problem is memory leaks, which is not a _huge_ problem for these
applications, since after the test application closes, the OS will clean up
any memory allocated in that process. ( at least NT/Win2K will do that
properly) On the other hand, creating code that doesn't cause memory leaks
is still much preferrable. This may be an issue in other places in the code
too, although the main problem area will only be the TestRunner DLL freeing
memory allocated elsewhere. 

On the other hand, if the base TestRunner class does the memory freeing
(deletes the suite), and it ends up in the cppunit (statically linked)
library, then we're okay. Perhaps this will work out more easily than I
first thought...

Guy


-----Original Message-----
From: Townsend, Guy [mailto:gto...@sh...]
Sent: Thursday, May 10, 2001 6:24 PM
To: 'cpp...@li...'
Subject: RE: [Cppunit-devel] hierarchy sample bug...


FWIW, I agree with the following solution.

>> To do cppunit:
>> - remove TestRegistry.cpp/.h 
>> - implement a TextTestRunner 
>> 
>> To do for the sample: 
>> - add a suite() method for each test case, which returns a 
>> dynamically allocated suite, 
>> - add the suite of each test case to the TextTestRunner, 
>> - run the TextTestRunner. 
>> => this would make it similar to run suite using a graphic or text 
>> TestRunner, and would show how test case should be factored. 

 As a cppunit newbie, this would make a lot of sense to me. There are so
many options that it's a little overwhelming. I also don't want to
restructure all my test code when the next release comes out. The proposed
solution would allow both automated text based tests and interactive tests,
from essentially the same code. This would be best accomplished if there
were slight changes to make TestRunner have a pure virtual run() method and
then have a TextTestRunner and a GuiTestRunner. The GuiTestRunners could
changed slightly for different platforms.

I realize I'm late to the discussion and perhaps I don't understand all the
issues. I see that there has so far been no effort to create a GUI
TestRunner for other platforms. (although I am extremely grateful that it
has been done for Windows, where I'm currently developing!!) Seems like at
least the base TestRunner class would end up in cppunit, with only the
platform specific parts in directories under src and in parallel with
cppunit and msvc6.

> OK, thanks for the explanation. Unfortunately until the weekend I don't
have the time to sort it out: got an exam this friday. So this would stall
the release of 1.5.5 until at least somewhere next week. If otherwise the
current tree is OK (and it is, isn't it?), I wouldn't want to deprive people
from Win32 support until then, and release 1.5.5 as an ad interim version.
May give us some useful feedback from others too. If there're are no
nay-sayers, I'll put it on source forge tomorrow. 

Thanks for getting the Win32 support out! I was doing many of the same fixes
to get in synch with the SoureForge version, but at least compile with MSVC.
Getting it all merged in was a real bonus! Saved me a lot of time.


I'm not sure how much time I can spare, but I am hoping that I can
contribute to some degree, including documentation. As usual, the docs are
secondary to getting working code (and getting the design bugs worked out).
I find myself jumping around a lot of different documents and geting
confused about all the new features that aren't really documented. Luckily I
can still use the basic classes and get useful work done. I've done a lot of
documentation in the past, including full databook writing and editing; and
actually don't mind it at all. (however I still have work deadlines to meet
first...) It's not clear to me however if it is worth updating the cookbook
until the next round of stuff with TestRunner is straightened up...

Hope this is not too much in one message, but I also suggest the suite()
method be added to either Test or TestCase. I have been seeing a lot of
discussion about this method, including in the CppUnit Cookbook document,
and it's confusing for it not to be a virtual method in one of the base
classes. It would also provide a good place to add some documentation for
its use.

Guy


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel