Re: Test Driving WPF

Hi Steve,

The fact that the user has to test the whole app anyway could be used as an
excuse to eliminate all kinds of testing. In fact is has been used that way.

In Windows days, "Make your GUI thin" and separate it from other logic was
what we told people as_a_starting_point. We then figured out how to test
that thin layer, depending on the importance of whatever the application
did and the risk associated with failure. GUIs for medical instruments, for
example, do actually need to be tested, however thin they may be.

I'm pretty sure there are ways to be discovered for testing WPF. I'd be
quite surprised if that way came out of Microsoft... it's more likely that
this community will eventually figure it out. Architectures like MVVM and
MVP help us move the untested stuff to tested. Some technologies tempt us
to keep more in the untested side and WPF seems to be one of them. But so
was Windows, and we still learned not to design apps the way the IDE
generated them for us. I hope that will happen with WPF as wll.


Let's remember that "thin GUI" is a half-way measure. Ask yourself what can
go wrong with your WPF and how you'll know when it does.

Charlie


On Mon, Nov 4, 2013 at 1:07 PM, Steven Gordon <[email protected]> wrote:

>
>
> It's software - of course, things can go wrong, even when there is 100%
> test coverage.
>
> Tests cannot fully specify/verify the usability of GUI by humans, so
> manual testing of the GUI is necessary anyway.  Just keep the GUI as thin
> as possible so that the logic and business rules are being
> specified/verified as well as possible,
>
>
> On Mon, Nov 4, 2013 at 1:44 PM, Charlie Poole <[email protected]>wrote:
>
>>
>>
>> So I guess nothing can go wrong! :-)
>>
>>
>> On Mon, Nov 4, 2013 at 12:38 PM, Steven Gordon <[email protected]>wrote:
>>
>>>
>>>
>>> A benefit of Avi's approach is that it highly encourages a thin GUI that
>>> delegates as much as possible to directly testable code that reside in
>>> other DLLs, which we all know results in a better, more adaptable
>>> architecture.
>>>
>>> Maybe, not being able to directly unit testing is ultimately not such a
>>> bad thing.
>>>
>>>
>>>
>>> On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> The general rule we have is to test the model and the controls that
>>>> dictate the changes to the UI, but the UI itself can't be tested with unit
>>>> tests.   Alternatively, you can try to take screen shots and try to do jpg
>>>> comparisons (but I don't recommend it)
>>>>
>>>> brought to you by the letters A, V, and I
>>>> and the number 47
>>>>
>>>>
>>>> On Mon, Nov 4, 2013 at 6:54 PM, Alan Baljeu <[email protected]>wrote:
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>  
>