Re: Test Driving WPF

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
>>
>>
>  
>