RE: [Cppunit-devel] TestRunner with MFC

[lacall <la...@mi...>]

FYI only--I finally got around this problem by avoiding use of TestRunner
even though it's an MFC app. I use TextTestRunner and redirect the stdout to
a file, and display the file. Fast & easy now. Uses a little code I found
via a google search to redirect stdout in MFC then display it. Thanks for
the help/info.

Here's what I do now, in case it is useful to anyone: 
#include <cppunit/TextTestRunner.h>
#include <cppunit/extensions/TestFactoryRegistry.h>
#include <stdio.h>
#include <stdlib.h>
....
then in a function called at application startup, when in the app's "test"
mode:

FILE *stream = freopen( "freopen.out", "w", stdout );
if( stream == NULL ) {
	AfxMessageBox("error on freopen before trying to run unit tests.");
} else {
	CppUnit::TextTestRunner runner;
	runner.addTest (
CppUnit::TestFactoryRegistry::getRegistry().makeTest() );
	runner.run ();

	fflush(stream);
	fclose(stream);
	system( "type freopen.out & pause" ); // displays results
	// also possible to redirect back to console (undoing the above; do
be4 close?):
	//		stream = freopen("CON", "w", stdout); 
}

Luke Call
EDM Group
Micron Technology, Boise


-----Original Message-----
From: Arlo Belshee [mailto:arl...@ho...]
Sent: Tuesday, March 12, 2002 2:40 PM
To: lacall; cpp...@li...
Subject: RE: [Cppunit-devel] TestRunner with MFC


We had this problem. In our case it had a very odd source.

Testrunner.dll (and testrunnerd.dll) were not including their resources when
they were built.

We could never firgure out why they built without resources, only that
sometimes they would have the resources and sometimes they wouldn't. If they
didn't, then many lookups would fail, and one of them would finally assert.

However, I don't know whether you're having the same problem. Thus, here is
a list of several other similar-looking problems that I've run into, and
their solutions.

1. Threading. CWnds can only be used on the same thread that they are
created on. As CDialogs are children of CWnds, the same is true of the
testrunner dialog. Thus, whichever thread causes the creation of the created
window (calls Create in the dialog - I don't remember which call on the test
runner dialog causes this to happen - run, add test or initial construction)
must be the same as thread which calls run (and actually displays the
dialog). For simplicity, make sure that all interactions with the dialog
happen from the same thread. This one bit us because we were running tests
on VMs emulating a distributed network.

2. MFC dll boundaries suck. If you are using an MFC DLL from a non-MFC
project, then the dll instance can get easily confused. Make sure that all
entrypoints into the DLL include the magic macro (AFX_MANAGE_STATE(), or
something like that). There are other requirements to make a regular DLL use
MFC without requiring that the application loading it use MFC, but that's
the biggie. If you are using this from an application that doesn't use MFC
(we were running it from a service), then you should probably read MS's help
on building regular DLLs that link to MFC, and how they are used.

2.1. On a related note, make sure that all of yoru test cases also have the
correct entry-point behavior. It is very easy to inherit incorrectly or
include something MFC-dependant and force your entire test to have to
include the magic macros (especially if you are creating your tests in a
DLL, and running them from a stub application). Dourblecheck yoru interfaces
to make sure that the MFC state is not corrupted.

We've run into a number of other issues as well, but they're not really
likely. If none of this helps, let me know. I may be able to come up with
something more.

Arlo

> -----Original Message-----
> From: cpp...@li...
>
> Any other possible ideas or things I should try? I plan on
> stepping through
> it in a debugger again to see what I can learn, but spent quite a bit of
> time on it already. (Thanks for the RTTI idea--it was worth
> double-checking.)
>
> Either way, thanks for a nice product--I hope to get some use out
> of it and
> show other members of our group how to use it, once I get this
> part working.
>
> ----- Original Message -----
> From: "lacall" <la...@mi...>
>
> > I'm wondering if someone could point me in the right direction on some
> kind
> > of bug in the way I'm using TestRunner. I seem to be using it
> exactly like
> > in the example code, and when I call runner.run() it launches the
> TestRunner
> > dialog just fine. But when I click the "Browse" button in TestRunner, I
> get
> > a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43.
> It is where
> > it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl
> is null (I
> > believe it is trying to get the handle to the parent dialog,
> but it gets a
> > null value).
> >
> > Interestingly, the tests seem to work ok with the TextTestRunner when
> called
> > identically from the app. I stepped through it and it worked
> great (except
> > that the std::cout test results aren't displayed, due to it being an MFC
> > app).
> >
> > Any ideas what I may be doing wrong to cause the error with TestRunner's
> > Browse button? I have stepped through the code extensively, comparing it
> to
> > the same code and execution path for the provided cppunit MFC examples,
> and
> > can't tell what's different; maybe this particular MFC issue is
> just over
> my
> > head a bit. Many thanks for any ideas!
> >
> > Luke Call
> > EDM Group
> > Micron Technology, Boise
> >
> >
> > _______________________________________________
> > Cppunit-devel mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>