Re: Test Driving WPF

Hi Alan,
I didn't find any such guidance last time I checked.. I wanted to create a
non-trivial example but procrastinated.

Caliburn looked interesting.. but no testability-oriented tutorials.
Don't step into Prism.. it has a different definition for MVVM. It is a
view-first framework.. and hence diff to test without the GUI.

.Net allows you to reference exe assemblies as well as dll assemblies - so
that's not a concern as far as unit-testing is concerned. You may still
want to keep your exe project thin.. as the general advice goes..
View and ViewModel in different projects - not sure how it'd help ...  I
usually keep them under named folders within the same project. The
ViewModel is part of the presentation layer and as such usually tends to be
hand-in-glove with the View..



On Wed, Nov 6, 2013 at 3:53 AM, Alan Baljeu <[email protected]> wrote:

>
>
> I have been searching a lot for some guidance and am coming up short.  Okay,
> maybe an easier question:
>
> I believe that to unit test, you need to have code in a class library
> project rather than an application project.  I also read that somebody
> suggests separating V and VM into two projects.  Do you think this is
> right?  Can anybody point me to instructions on doing this?
>
> Alan Baljeu
>
>   ------------------------------
>  *From:* Alan Baljeu <[email protected]>
> *To:* "[email protected]" <
> [email protected]>
> *Sent:* Tuesday, November 5, 2013 3:01:39 PM
>
> *Subject:* Re: [TDD] Test Driving WPF
>
>
>  Not a clue.  I'm presently trying to find a tutorial on TDD with
> Caliburn.Micro.
>
> Alan Baljeu
>
>   ------------------------------
>  *From:* Charlie Poole <[email protected]>
> *To:* [email protected]
> *Sent:* Tuesday, November 5, 2013 2:47:55 PM
> *Subject:* Re: [TDD] 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
>
>
>
>
>
>
>
>
>
>
>
>
>   
>