Re: Test Driving WPF

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