Phlip | 15 Jun 03:40 2007
Picon

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/
(Continue reading)

Phlip | 15 Jun 14:02 2007
Picon

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

Donaldson, John (GEO) wrote:

> not specific to MFC, but still worth bearing in mind if you haven't
> already is make the presentation layer as thin as possible. Apply the
> "Humble Dialog" principle. That way you can disentangle yourself from the
> gory details of MFC quickly.

Modulo the legacy implications.

Tip: Find the lowest-level functions you can, maybe things as simple as a
glorified strcat(), and write unit tests on them.

Put the unit tests into a suite, and link this from both your main app,
using
the /in vivo/ test technique, _and_ into a console-only test program.

Now slowly but relentlessly put as many lines of code under the command of
tests in the console-ready suites, so eventually the console-only test
program does the most work.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Phlip | 15 Jun 14:06 2007
Picon

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/

Anthony Williams | 15 Jun 16:07 2007
Picon

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/

Phlip | 18 Jun 18:24 2007
Picon

[TFUI] Re: [TDD] TDD wih GWT

Josue Barbosa dos Santos wrote:

> Anyone knows if there is something similar to the GWT (Google Web Toolkit)
> development? Is anyone here doing TDD with GWT?

I TDD Ajax using Ruby on Rails using these techniques:

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

The goal is all unit tests work with the "mock the server" technique.
No real web server or web browser at test time. Rails makes that
super-easy, and everyone should learn from its system.

After you can mock a server, and return its pages as strings, you
write pages with pure XHTML, and use assert_xpath to query out the
target items. Then you use assert_js to parse the JavaScript hooks
inside them, and that enables TDD for the browser side of the Ajax
calls.

All these techniques should port easily to other platforms. You should
get with the GWT mailing list, and share anything you learn that's
specific to GWT.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!

__._,_.___
Recent Activity
Visit Your Group
SPONSORED LINKS
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___
Jim Shore | 21 Jun 09:43 2007

[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 

Gmane