RE: Test Driving WPF

Alan,

When I was last working on an app with WPF I was trying to test the GUI layer by doing things like "press button" and verifying that the presenters got events.
I seem to remember that I had to add some methods to actually allow pressing buttons and selecting list items and so on - but it was simple enough and worked well enough for me to feel confident.

Of course, I was also running the whole thing to see that it was making visual sense.

I think it may be goodness to keep away from testing for visual aspects (your example of a medium-complex double list control...).
That way it's easy to change the look-and-feel while still leaving the functionality.

So:

-          Just handle the events emitted from the GUI.

-          Make sure the GUI handles its responsibilities.

-          Inspect the GUI.

John D.

From: [email protected] [mailto:[email protected]] On Behalf Of Alan Baljeu
Sent: 04 November 2013 17:55
To: [email protected]
Subject: [TDD] Test Driving WPF




I'm kind of new to WPF and trying to TDD an application that uses it.  I'm a little frustrated that Microsoft's default program architecture still isn't TDD friendly.  It creates an application project and adds a window and an app level resource dictionary, none of which can be tested because a test system requires a DLL it can load.  But if I create a new DLL, it loses connection to the base resources because that's in the exe and not available in testing.

So the architecture seems wrong, and I don't know what's a more ideal way to proceed.  Or, is there something I'm missing about testing UI code.

Alan Baljeu