Re: Test Driving WPF

Avi Kessner <[email protected]>
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CAGEhWpFRuNU0rJPCLLUx5AMUjN5OafWd8f=0uy_GA+21RQu9mQ@mail.gmail.com>
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
>>
>>
>>
>>
>>
>  
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.