Re: Test Driving WPF

Alan, it sounds to me like you are on the right track.
On 5 Nov 2013 09:06, "Avi Kessner" <[email protected]> wrote:

> Just because you can't unit test the gui doesn't mean you avoid testing
> the gui.  You can't TDD yourself towards a good GUI.  But you can write
> acceptance tests after the fact.  When I was working on a windows phone
> app, what we did was create multiple projects.  One project was only the
> xaml code.  The other project was all our code which could be unit tested.
> (Ok, so technically it was 3 projects cause we had one with all the unit
> tests)
> On 5 Nov 2013 03:30, "Charlie Poole" <[email protected]> wrote:
>
>>
>>
>> From my (very little) experience with WPF, DataBinding is where the
>> testing gets hard. Of course, you don't want to test that databinding
>> works, since it's part of WPF, but there's always the risk that you not set
>> it up correctly. That's a piece I don't really know how to test except by
>> looking at the GUI.
>>
>> Charlie
>>
>>
>> On Mon, Nov 4, 2013 at 2:33 PM, Alan Baljeu <[email protected]> wrote:
>>
>>>
>>>
>>> Well yes, I consider MVVM a given, and Caliburn.Micro looks like a good
>>> option.  Now for testing a view I think I should want a fake ViewModel that
>>> just gives the view fixed data in order to see how well this data or that
>>> data are presented.  But I'm not at all sure about this concept.
>>>
>>> (At the moment I'm just drawing stuff in WPF just for gauging looks.
>>>  Not even a hint of logic is going anywhere.  At some point I'll have to
>>> refactor and then introduce databinding etc.)
>>>
>>>
>>> Alan Baljeu
>>>
>>>
>>>   On Monday, November 4, 2013 4:44:27 PM, David Vílchez <
>>> [email protected]> wrote:
>>>
>>>  What's about MVVM and test the view model?
>>>
>>> I would look for Caliburn.Micro
>>>
>>> Sent from my iPad
>>>
>>> On 04/11/2013, at 20:55, 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
>>>
>>>
>>>
>>>
>>>
>>  
>>
>