Re: Test Driving WPF

Yup, me too! More recently, I've done the same using a mock view.

Do you know how to do the same / similar with WPF?

Charlie


On Tue, Nov 5, 2013 at 6:20 AM, Alan Baljeu <[email protected]> wrote:

>
>
> In earlier times with Windows Forms I did something like this:
>
> [Test]
> void Test()
> {
>   var presenter = new Presenter();
>   var view = new View(presenter);
>   view.Show();
>   presenter.model.x = 3;
>   Assert.That(view.xcontrol.Value == 3);
> }
>
> The details may be wrong but that was the concept.
>
> Alan Baljeu
>   ------------------------------
>  *From:* Charlie Poole <[email protected]>
> *To:* [email protected]
> *Sent:* Monday, November 4, 2013 8:30:37 PM
> *Subject:* Re: [TDD] Test Driving WPF
>
>
>  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
>
>
>
>
>
>
>
>   
>