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