¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: [TDD] Test Driving WPF

 

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 wrote:
?
What's about MVVM and test the view model?

I would look for Caliburn.Micro


On 04/11/2013, at 20:55, Avi Kessner <akessner@...> 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 <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

 

Hi Steve,

The fact that the user has to test the whole app anyway could be used as an excuse to eliminate all kinds of testing. In fact is has been used that way.

In Windows days, "Make your GUI thin" and separate it from other logic was what we told people as_a_starting_point. We then figured out how to test that thin layer, depending on the importance of whatever the application did and the risk associated with failure. GUIs for medical instruments, for example, do actually need to be tested, however thin they may be.

I'm pretty sure there are ways to be discovered for testing WPF. I'd be quite surprised if that way came out of Microsoft... it's more likely that this community will eventually figure it out. Architectures like MVVM and MVP help us move the untested stuff to tested. Some technologies tempt us to keep more in the untested side and WPF seems to be one of them. But so was Windows, and we still learned not to design apps the way the IDE generated them for us. I hope that will happen with WPF as wll.


Let's remember that "thin GUI" is a half-way measure. Ask yourself what can go wrong with your WPF and how you'll know when it does.

Charlie


On Mon, Nov 4, 2013 at 1:07 PM, Steven Gordon <sgordonphd@...> wrote:
?

It's software - of course, things can go wrong, even when there is 100% test coverage.

Tests cannot fully specify/verify the usability of GUI by humans, so manual testing of the GUI is necessary anyway. ?Just keep the GUI as thin as possible so that the logic and business rules are being specified/verified as well as possible,


On Mon, Nov 4, 2013 at 1:44 PM, Charlie Poole <charliepoole@...> wrote:
?

So I guess nothing can go wrong! :-)


On Mon, Nov 4, 2013 at 12:38 PM, Steven Gordon <sgordonphd@...> wrote:
?

A benefit of Avi's approach is that it highly encourages a thin GUI that delegates as much as possible to directly testable code that reside in other DLLs, which we all know results in a better, more adaptable architecture.

Maybe, not being able to directly unit testing is ultimately not such a bad thing.



On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <akessner@...> 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 <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 haven't done much with WPF for a couple of years but you can use MVVM and unit test the subcutaneous layer or you can use an automation tool like White?


On 4 Nov 2013, at 16:54, 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

 

It's software - of course, things can go wrong, even when there is 100% test coverage.

Tests cannot fully specify/verify the usability of GUI by humans, so manual testing of the GUI is necessary anyway. ?Just keep the GUI as thin as possible so that the logic and business rules are being specified/verified as well as possible,


On Mon, Nov 4, 2013 at 1:44 PM, Charlie Poole <charliepoole@...> wrote:
?

So I guess nothing can go wrong! :-)


On Mon, Nov 4, 2013 at 12:38 PM, Steven Gordon <sgordonphd@...> wrote:
?

A benefit of Avi's approach is that it highly encourages a thin GUI that delegates as much as possible to directly testable code that reside in other DLLs, which we all know results in a better, more adaptable architecture.

Maybe, not being able to directly unit testing is ultimately not such a bad thing.



On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <akessner@...> 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 <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

 

Okay so I want to make a medium fancy list control on a page of a dialog, where each element of the list has a bunch of dropdowns arranged and styled nicely, and with contents of these dropdowns being intelligently assigned by the application logic.

What's your process for constructing this?
1. Create WPF application.
2. Create WPF user-control project.
3. ???

Alan Baljeu



On Monday, November 4, 2013 3:44:25 PM, Charlie Poole wrote:
?
So I guess nothing can go wrong! :-)


On Mon, Nov 4, 2013 at 12:38 PM, Steven Gordon <sgordonphd@...> wrote:
?
A benefit of Avi's approach is that it highly encourages a thin GUI that delegates as much as possible to directly testable code that reside in other DLLs, which we all know results in a better, more adaptable architecture.

Maybe, not being able to directly unit testing is ultimately not such a bad thing.



On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <akessner@...> 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 <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

 

So I guess nothing can go wrong! :-)


On Mon, Nov 4, 2013 at 12:38 PM, Steven Gordon <sgordonphd@...> wrote:
?

A benefit of Avi's approach is that it highly encourages a thin GUI that delegates as much as possible to directly testable code that reside in other DLLs, which we all know results in a better, more adaptable architecture.

Maybe, not being able to directly unit testing is ultimately not such a bad thing.



On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <akessner@...> 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 <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

 

A benefit of Avi's approach is that it highly encourages a thin GUI that delegates as much as possible to directly testable code that reside in other DLLs, which we all know results in a better, more adaptable architecture.

Maybe, not being able to directly unit testing is ultimately not such a bad thing.


On Mon, Nov 4, 2013 at 12:55 PM, Avi Kessner <akessner@...> 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 <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

 

"The UI itself can't be tested with unit tests." ?Do you mean to suggest the UI itself won't be tested? ?You say controls should be tested, but how can you do this in the context of WPF which likes to put resources at the application level? ?Or maybe (I don't know this toolkit enough) the resources and such don't need testing because it's all style and not functional.
?
Alan Baljeu


On Monday, November 4, 2013 2:56:17 PM, Avi Kessner 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 <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

David V¨ªlchez
 

¿ªÔÆÌåÓý

What's about MVVM and test the view model?

I would look for Caliburn.Micro


On 04/11/2013, at 20:55, Avi Kessner <akessner@...> 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 <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

 

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
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.
?
Alan Baljeu
Re: [TDD] Design & Evolution of TDD?

 

?PLoP = Pattern Languages of Programs, as far as I remember.

Check:

AgileDenver October 28: Stephan Hagemann on "Agility and the Go language"

 

On Monday, October 28, Agile Denver will host guest speaker Stephan Hagemann. Stephan will present on the Go language (golang). Go was invented at Google and includes enhancements that can make it more productive for Agile teams, such as increased testability.


Stephan will provide a brief introduction to Go from an Agile programmer's perspective, explore Go's testability in some depth, and then compare an Go in the Agile context to other common languages like Java and C/C++.


Stephan is an Engineering Manager at Pivotal Labs in Boulder. For most of his days that means writing software. Currently he contributes to the Cloud Foundry PAAS by helping develop its user logging infrastructure, which is entirely written in Go. With every project he especially enjoys the continuous search for doing the right thing, and doing that right.


Please see http://agiledenver.ning.com/events/agile-denver-201310 for more information.
Re: [TDD] Unit tests and parameter validation

 

Keith Ray wrote:
If "outside" is GUI/user and "inside" is using a framework or
database, then there can be a mis-match, when you find out the
database needs info not yet provided by the GUI/user, or that the
framework requires asynchronous behavior when the GUI assumes simple
synchronous behavior.
In that case you just got pwned by a framework. Ouch.

Adding to what I said before, the in/out view blurs if you create thin
verticals, which you should, but even then I prefer going from the Big
Test (which really isn't that big at first).

Michal
Re: [TDD] Unit tests and parameter validation

 

Where does that data come from?

Programmers or external sources?

Development time or runtime?

I don't test against programmers but might test if data comes from a file or database. Humans can figure out when they're wrong, especially if they write tests.

Of course I worry a bit more if the parameters are not type-safe and/or the ordering of parameters is not obvious and natural.

So that leaves the last question as whether the interface invited advise.

On Oct 16, 2013 12:03 AM, "Eb" <amaeze@...> wrote:



Hello everyone -

I'm curious to know thoughts on writing tests that specify the behavior of a method when its inputs are incorrect. ?Is this a common practice. ?How about parameter validation in this case? ?Having some healthy debate on it and wanted to get other insight.

The context for this in a class/methods that are used within an internal application - this is not an API that will be publicly exposed to external consumers.

Thanks.

--
blog:
twitter: @eikonne
[TDD] Unit tests and parameter validation

 

IIRC, the?terms London and Detroit school were dreamt up on this list as a reaction to the negative reactions to "mockist/statist" terminology. Can't remember who suggested them, but they stuck at least for a while. The?reason the top down mock based approach is called London school is that Steve and Nat wrote about it and they live in London. The reason the other approach is called Detroit school?is Ron and some of?the other early XP guys live in the vicinity.?

On Monday, October 21, 2013, Josue Barbosa dos Santos wrote:
?

On Sun, Oct 20, 2013 at 4:54 AM, Ron Jeffries?<ronjeffries@...>?wrote:
?And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all.

Speaking about Detroit and London Schools, did you read the book Growing Object Oriented Software Guided by Tests (GOOS) from Steve Freeman an Nat Price? Just curious.

--?
Abra?os,
´³´Ç²õ³Ü¨¦



On Sun, Oct 20, 2013 at 4:54 AM, Ron Jeffries <ronjeffries@...> wrote:
?

Hi David,


On Oct 20, 2013, at 2:00 AM, "Parsons, David" <d.p.parsons@...> wrote:

An interesting discussion. I must admit that it hadn't really occurred to me that much parameter validation could be a complete waste of time, so thanks for the insight.?

It does seem to me that even if you develop 'inside out' you will sometimes need to work 'outside in', for example if you are using a mock, or if you apply refactorings that extract classes or methods.

In fact I generally work "outside-in", with occasional experiments on "I wonder whether, if I took this course, I could make such and so happen", where I'll build some inside thing. I would save that thing for reference, perhaps, but would not expect to use it as is. The experiment would be to teach me what's possible and a bit about how to do it. Then I'd let my usage of the thing tell me what it wants to be.

And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all.

Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl




Re: [TDD] Re: Unit tests and parameter validation

 

On Sun, Oct 20, 2013 at 4:54 AM, Ron Jeffries?<ronjeffries@...>?wrote:
?And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all.

Speaking about Detroit and London Schools, did you read the book Growing Object Oriented Software Guided by Tests (GOOS) from Steve Freeman an Nat Price? Just curious.

--?
Abra?os,
´³´Ç²õ³Ü¨¦



On Sun, Oct 20, 2013 at 4:54 AM, Ron Jeffries <ronjeffries@...> wrote:
?

Hi David,


On Oct 20, 2013, at 2:00 AM, "Parsons, David" <d.p.parsons@...> wrote:

An interesting discussion. I must admit that it hadn't really occurred to me that much parameter validation could be a complete waste of time, so thanks for the insight.?

It does seem to me that even if you develop 'inside out' you will sometimes need to work 'outside in', for example if you are using a mock, or if you apply refactorings that extract classes or methods.

In fact I generally work "outside-in", with occasional experiments on "I wonder whether, if I took this course, I could make such and so happen", where I'll build some inside thing. I would save that thing for reference, perhaps, but would not expect to use it as is. The experiment would be to teach me what's possible and a bit about how to do it. Then I'd let my usage of the thing tell me what it wants to be.

And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all.

Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl




Re: [TDD] Re: Unit tests and parameter validation

 

¿ªÔÆÌåÓý

Hi David,

On Oct 20, 2013, at 2:00 AM, "Parsons, David" <d.p.parsons@...> wrote:

An interesting discussion. I must admit that it hadn't really occurred to me that much parameter validation could be a complete waste of time, so thanks for the insight.?

It does seem to me that even if you develop 'inside out' you will sometimes need to work 'outside in', for example if you are using a mock, or if you apply refactorings that extract classes or methods.

In fact I generally work "outside-in", with occasional experiments on "I wonder whether, if I took this course, I could make such and so happen", where I'll build some inside thing. I would save that thing for reference, perhaps, but would not expect to use it as is. The experiment would be to teach me what's possible and a bit about how to do it. Then I'd let my usage of the thing tell me what it wants to be.

And either direction, parameter checking would be rare. As would mocks, being as I'm Detroit School and all.

Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl

Re: [TDD] Re: Unit tests and parameter validation

 

I will be honest.?? Except for the most basic of VOs I don't know how you can be sure of what is 'inside' and what is 'outside'.? Sometimes even your GUI becomes a component for a wrapper.

On 20 Oct 2013 09:00, "Parsons, David" <d.p.parsons@...> wrote:

?

An interesting discussion. I must admit that it hadn't really occurred to me that much parameter validation could be a complete waste of time, so thanks for the insight.?

It does seem to me that even if you develop 'inside out' you will sometimes need to work 'outside in', for example if you are using a mock, or if you apply refactorings that extract classes or methods.

Dave Parsons
Re: Unit tests and parameter validation

 

¿ªÔÆÌåÓý

An interesting discussion. I must admit that it hadn't really occurred to me that much parameter validation could be a complete waste of time, so thanks for the insight.?

It does seem to me that even if you develop 'inside out' you will sometimes need to work 'outside in', for example if you are using a mock, or if you apply refactorings that extract classes or methods.

Dave Parsons
861 - 880 of 36280