Re: [TDD] Test Driving WPF
Yes, sorry if I wasn't clear. the XAML and the underlying .cs file would be in the same project. But the actual Model, controllers, and other services which are pure code and don't rely on a GUI would be in a separate project. ?(Mainly to deal with the resources issue)
On Wed, Nov 6, 2013 at 11:33 AM, Gishu Pillai <gishu.pillai@...> wrote:
?
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.
|
Re: [TDD] 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.
On Wed, Nov 6, 2013 at 3:53 AM, Alan Baljeu <alanbaljeu@...> 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
?
Not a clue. ?I'm presently trying to find a tutorial on TDD with Caliburn.Micro.
? Alan Baljeu
?
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 <alanbaljeu@...> 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 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 <alanbaljeu@...> 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 <dvilchez@...> wrote:
?
What's about MVVM and test the view model?
I would look for Caliburn.Micro
?
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 <alanbaljeu@...> 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
|
Re: [TDD] Test Driving WPF
:)
What I meant: Windows forms was very event driven.. you keep hooking onto events exposed by objects and fill in the handlers. WPF offers no corresponding events.. it's MVVM or the highway.
Gishu
On Wed, Nov 6, 2013 at 1:22 AM, Charlie Poole <charliepoole@...> wrote:
?
Nice summary. I like "mapping old experience doesn't work" ... except it's the only kind I have. :-)
Charlie
|
Re: [TDD] Test Driving WPF
This may or may not help:
Charlie
On Tue, Nov 5, 2013 at 2:23 PM, Alan Baljeu <alanbaljeu@...> 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
?
Not a clue. ?I'm presently trying to find a tutorial on TDD with Caliburn.Micro.
? Alan Baljeu
?
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 <alanbaljeu@...> 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 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 <alanbaljeu@...> 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 <dvilchez@...> wrote:
?
What's about MVVM and test the view model?
I would look for Caliburn.Micro
?
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 <alanbaljeu@...> 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
|
Re: [TDD] Test Driving WPF
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
To: "testdrivendevelopment@..."
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
To: testdrivendevelopment@...
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
|
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 To: testdrivendevelopment@...
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
?
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 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 <alanbaljeu@...> 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 <dvilchez@...> wrote:
?
What's about MVVM and test the view model?
I would look for Caliburn.Micro
?
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 <alanbaljeu@...> 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
|
Re: [TDD] Test Driving WPF
Nice summary. I like "mapping old experience doesn't work" ... except it's the only kind I have. :-)
Charlie
On Tue, Nov 5, 2013 at 7:16 AM, Gishu Pillai <gishu.pillai@...> wrote:
?
Having difficulty visualizing what you're trying to build.
Here's whats worked for me... - Use MVVM because otherwise you'd be fighting WPF most of the time.. Windows Forms and WPF are different beasts .. so mapping old experience mostly doesn't work.
- ViewModel: Your view model should hold the state for the view. This means that you can trigger it via changing "Properties" or executing 'Commands' and inspect the results. (State based testing)
- Model: You can verify whether the view model invokes the right methods on the backing model - Use state/interaction based style as you find comfortable. You can usually test the Model independently because it generally has no dependencies on either the VM or the View.
- View: I'm mostly okay with not testing this at all because usually it should just contain "Bindings". Frameworks like Caliburn use convention to auto-magically bind view controls to VM properties/commands. Minimize any code in the code-behind
- Finally you'll still have tests where you need to test interaction between multiple viewmodels or you just had to write some code in the code-behind (because the MVVM way was too hard - e.g. testing default focus) - I've had some amount of success with white (not called teststack.white) which drives GUIs on Windows.?
Special mentions: Bypass the dispatcher - this is a 'golden rule' of windows GUI - a UI element should only be accessed from the thread on which it was created. This means that once you're done doing the heavy lifting on a worker thread, you need to channel the UI updation back on to the main/UI thread. You usually do this by saying UIControl.Dispatcher.Invoke() / BeginInvoke()
In your tests, there won't be a UI Thread - so you need to fake this and make it just a Sync Invoke() HTH Gishu
PS: It can be done :)
|
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
?
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 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 <alanbaljeu@...> 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 <dvilchez@...> wrote:
?
What's about MVVM and test the view model?
I would look for Caliburn.Micro
?
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 <alanbaljeu@...> 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
|
Re: [TDD] Re: Test Driving WPF
I ran across this the other day...
Microsoft UI Automation library
"In this month's column, I will show you how to get started with UI test automation using the new Microsoft UI Automation library, which is included in the .NET Framework 3.0 as part of Windows Presentation Foundation (WPF)."
On Tue, Nov 5, 2013 at 5:30 AM, Reuven Yagel <reuven.yagel@...> wrote:
?
There is a nice new infoq article by Henri Kniberg in which he demonstrates a simple method for testing below the UI layer
--
Bill Arnette
|
I found pex useful for teaching the concept
?
Hi, I was wondering how I would go about finding TDD's in C# for my company. Any suggestions would be greatly appreciated.
Kind regards, E
|
Re: [TDD] Test Driving WPF
At present, I'm simply trying to build an understanding of good TDD with WPF. ?I'd love to find a tutorial for Caliburn.Micro that demonstrates test-driving. ?I think the prerequisite for this is to push these classes into class library projects, and I'm not seeing that out there.
(Eventually I want to make a multipage form, but just anything to get me
understanding is good now. ?I have a vague sense that Caliburn represents a way of thinking I'm not accustomed to. ?Reading more now.) ?
Alan Baljeu
From: Gishu Pillai
To: testdrivendevelopment@...
Sent: Tuesday, November 5, 2013 10:16:02 AM
Subject: Re: [TDD] Test Driving WPF
?
Having difficulty visualizing what you're trying to build.
Here's whats worked for me... - Use MVVM because otherwise you'd be fighting WPF most of the time.. Windows Forms and WPF are different beasts .. so mapping old experience mostly doesn't work.
- ViewModel: Your view model should hold the state for the view. This means that you can trigger it via changing "Properties" or executing 'Commands' and inspect the results. (State based testing)
- Model: You can verify whether the view model invokes the right methods on the backing model - Use state/interaction based style as you find comfortable. You can usually test the Model independently because it generally has no dependencies on either the VM or the View.
- View: I'm mostly okay with not testing this at all because usually it should just contain "Bindings". Frameworks like Caliburn use convention to auto-magically bind view controls to VM properties/commands. Minimize any code in the code-behind
- Finally you'll still have tests where you need to test interaction between multiple viewmodels or you just had to write some code in the code-behind (because the MVVM way was too hard - e.g. testing default focus) - I've had some amount of success with white (not called teststack.white) which drives GUIs on Windows.?
Special mentions: Bypass the dispatcher - this is a 'golden rule' of windows GUI - a UI element should only be accessed from the thread on which it was created. This means that once you're done doing the heavy lifting on a worker thread, you need to channel the UI updation back on to the main/UI thread. You usually do this by saying UIControl.Dispatcher.Invoke() / BeginInvoke()
In your tests, there won't be a UI Thread - so you need to fake this and make it just a Sync Invoke() HTH Gishu
PS: It can be done :)
|
Re: [TDD] Test Driving WPF
Having difficulty visualizing what you're trying to build.
Here's whats worked for me... - Use MVVM because otherwise you'd be fighting WPF most of the time.. Windows Forms and WPF are different beasts .. so mapping old experience mostly doesn't work.
- ViewModel: Your view model should hold the state for the view. This means that you can trigger it via changing "Properties" or executing 'Commands' and inspect the results. (State based testing)
- Model: You can verify whether the view model invokes the right methods on the backing model - Use state/interaction based style as you find comfortable. You can usually test the Model independently because it generally has no dependencies on either the VM or the View.
- View: I'm mostly okay with not testing this at all because usually it should just contain "Bindings". Frameworks like Caliburn use convention to auto-magically bind view controls to VM properties/commands. Minimize any code in the code-behind
- Finally you'll still have tests where you need to test interaction between multiple viewmodels or you just had to write some code in the code-behind (because the MVVM way was too hard - e.g. testing default focus) - I've had some amount of success with white (not called teststack.white) which drives GUIs on Windows.?
Special mentions: Bypass the dispatcher - this is a 'golden rule' of windows GUI - a UI element should only be accessed from the thread on which it was created. This means that once you're done doing the heavy lifting on a worker thread, you need to channel the UI updation back on to the main/UI thread. You usually do this by saying UIControl.Dispatcher.Invoke() / BeginInvoke()
In your tests, there won't be a UI Thread - so you need to fake this and make it just a Sync Invoke() HTH Gishu
PS: It can be done :)
|
Re: [TDD] Test Driving WPF
How do you write acceptance tests? ? Alan Baljeu
From: Avi Kessner
To: testdrivendevelopment@...
Sent: Tuesday, November 5, 2013 2:06:11 AM
Subject: Re: [TDD] Test Driving WPF
?
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" < charliepoole@...> 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
|
Re: [TDD] Test Driving WPF
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
To: testdrivendevelopment@...
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
|
Hi, I was wondering how I would go about finding TDD's in C# for my company. Any suggestions would be greatly appreciated. Kind regards, E
|
There is a nice new infoq article by Henri Kniberg in which he demonstrates a simple method for testing below the UI layer
|
Re: [TDD] Test Driving WPF
Alan,
?
When I was last working on an app with WPF I was trying to test the GUI layer by doing things like ¡°press button¡± and verifying that the presenters got events.
I seem to remember that I had to add some methods to actually allow pressing buttons and selecting list items and so on ¨C but it was simple enough and worked
well enough for me to feel confident.
?
Of course, I was also running the whole thing to see that it was making visual sense.
?
I think it may be goodness to keep away from testing for visual aspects (your example of a medium-complex double list control¡).
That way it¡¯s easy to change the look-and-feel while still leaving the functionality.
?
So:
-?????????
Just handle the events emitted from the GUI.
-?????????
Make sure the GUI handles its responsibilities.
-?????????
Inspect the GUI.
?
John D.
?
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
On Behalf Of Alan Baljeu
Sent: 04 November 2013 17:55
To: testdrivendevelopment@...
Subject: [TDD] Test Driving WPF
?
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.
|
Re: [TDD] Test Driving WPF
Alan, it sounds to me like you are on the right track.
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" < charliepoole@...> 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
|
Re: [TDD] Test Driving WPF
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)
?
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
|
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 <alanbaljeu@...> 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 <dvilchez@...> wrote:
?
What's about MVVM and test the view model?
I would look for Caliburn.Micro
?
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 <alanbaljeu@...> 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
|
