Re: [Cppunit-devel] TestRunner with MFC

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I usually run the unit test as a post-build step, using the compiler
outputter (just press F4 and you jump right to the failed assertion).

See http://sourceforge.net/forum/message.php?msg_id=1509772 for detail.

Baptiste.

----- Original Message -----
From: "lacall" <la...@mi...>
To: "'Arlo Belshee'" <arl...@ho...>;
<cpp...@li...>
Sent: Monday, March 18, 2002 6:47 PM
Subject: RE: [Cppunit-devel] TestRunner with MFC

> 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
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>