Re: TDD:ing MFC

Paula S. wrote:

> I know some people are successfully doing TDD with VC++ MFC. I'm currently 
> trying to add unit tests to a legacy MFC application and need some help to 
> get started testing dialogs and windows. Some pointers in the right 
> direction would be much appreciated.

MFC has major architectural flaws that resist clean testing. One good policy 
is to use "in vivo" testing, per the book /Working Effictively with Legacy 
Code/ by Mike Feathers. That means you start the application's main work 
loop, and after the main window has painted you encounter a line of code 
like this:

#ifdef DEBUG
      runTests(mainHwnd);
#end

That means when you run your program from VC++, in Debug mode it will invoke 
a test rig, and pass in a handle to the main window. The tests now operate 
on the window, treating all its subwindows and controls as objects.

I would use UnitTest++ for the test rig. It's designed to be lean and 
non-invasive (unlike MFC), so you'll easily squeeze it into the runTests() 
function.

Ask about any more questions!

--

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/

[TFUI] Re: [TDD] TDD:ing MFC

Re: Re: TDD:ing MFC

Anthony Williams wrote:

>> I know some people are successfully doing TDD with VC++ MFC. I'm
>> currently trying to add unit tests to a legacy MFC application and
>> need some help to get started testing dialogs and windows. Some
>> pointers in the right direction would be much appreciated.
>
> Testing dialogs is really easy unless they assume too much about the rest 
> of
> the environment. The trick is to create them as non-modal dialogs rather 
> than
> running DoModal()

+1

Windows has various subtle bugs regarding DoModal(). One should treat it as 
a convenience function for lazy programming. Make the dialog modeless, and 
disable the parent window when it's up. That's the exact same effect. (Or 
improve your GUI usability, and make the dialog completely modeless...)

> so you can then prod them from the tests. I've written a
> bunch of helper functions for simulating various user actions on a dialog 
> by
> sending the appropriate sequence of messages. You can then simulate e.g. a
> selection of an item from a combo drop-down, or a double-click on a list 
> item,
> or a user entering data in a text box and assert on the consequences.

I suspect all such functions can run without displaying the window. And they 
certainly don't run like capture-playback tests...

> One complication is when a user action is then supposed to open another 
> modal
> dialog, which then steals control from your tests. I've found that the 
> best
> way to do this is to isolate the interaction with the new dialog in a
> function, and then stub out that function for testing purposes e.g. by 
> making
> it virtual and creating a derived class for testing, or by moving it to a
> callback and providing a dummy callback. Depending on what you're testing, 
> you
> can then assert on the data provided to the new dialog, or substitute
> different responses.
>
> Standard message boxes can be dealt with the same way, or you can start a 
> new
> thread in the test to watch for new message boxes created by your process 
> and
> click on an appropriate button to close them.
>
> MFC does expect your application to have a particular structure, so you 
> might
> have to create an instance of a CWinApp-derived class in order to make 
> things
> work, but it's relatively easy to create a simple framework that does just
> enough for the tests to run.
>
> One problem I've had when unit-testing legacy MFC apps is that they also 
> seem
> to suffer from many other legacy app issues, such as using global 
> variables to
> communicate between disjoint parts of the application, so a lot of the 
> setup
> for tests can be ensuring that the global variables are all initialized
> correctly.
>
> Anthony

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:testdrivendevelopment-digest <at> yahoogroups.com 
    mailto:testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: TDD:ing MFC

"Phlip" <phlip2005 <at> gmail.com> writes:

> Anthony Williams wrote:
>> I've written a
>> bunch of helper functions for simulating various user actions on a dialog 
>> by
>> sending the appropriate sequence of messages. You can then simulate e.g. a
>> selection of an item from a combo drop-down, or a double-click on a list 
>> item,
>> or a user entering data in a text box and assert on the consequences.
>
> I suspect all such functions can run without displaying the window. 

Absolutely. One of my helper functions is called windowWouldBeVisible() --- I
use it to verify that controls are correctly hidden or shown as appropriate,
even when the dialog is not actually displayed. 

I always create the window, but without the WS_VISIBLE flag, so it's never
actually shown.

> And they certainly don't run like capture-playback tests...

No. Everything is based on control ID rather than mouse movements. The
simulation functions verify that the control is present, and of the
appropriate type, and then fire the appropriate sequence of messages as-if the
user had done a particular action. Sometimes I don't bother with the full set
of messages, if I know that I only need a couple in order to get the effect I
require, but I can always extend the simulation functions when more accurate
representation is required.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:testdrivendevelopment-digest <at> yahoogroups.com 
    mailto:testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[TFUI] Re: [TDD] TDD wih GWT

[ANN] NUnitAsp v2.0 released

I'm happy to announce the release of NUnitAsp v2.0.  NUnitAsp is a  
tool for test-driven development of ASP.NET code-behind.

NUnitAsp 2.0 contains a significant set of improvements over 1.5.1.   
The most important new features are:

     *  Tests ASP.NET 2.0.
     * Works with any version of any testing framework.
     * Supports multiple forms.
     * Tests can directly modify form variables, submit forms, and  
post-back forms.
     * Added a boatload of new testers, including a generic tester  
for any HTML tag.
     * Supports using XPath to find HTML tags.
     * Removed need to use CurrentWebForm parameter.
     * Added Advanced NUnitAsp video.

NUnitAsp v2.0 is available for download at: https://sourceforge.net/ 
project/showfiles.php?group_id=49940.

A detailed change log may be found at: http:// 
nunitasp.sourceforge.net/changes.txt

The NUnitAsp website is at http://nunitasp.sourceforge.net.

James Shore
Project Coordinator
NUnitAsp

[Non-text portions of this message have been removed]

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com