views:

43

answers:

2

Hi All

I'm just getting started in the exciting world of WPF development, having been a C++ developer for many years.

Testing applications with rich user interfaces has of course, always been hard. One of the problems compounding this has traditionally been that in most Windows apps, the UI, the UI logic and the App logic are all completely interdependent, and cannot be tested in isolation.

I'm very drawn to the MVVM approach that will allow me to separate the UI from the application, and run large amounts of automated tests on my view models, underneath which all my logic will be, with the view being a fairly dumb client of the view model.

That's all well and good, and neatly separates out testing of the application logic from the application UI. BUT, it provides no solution for actually testing the UI itself. Even though the view will typically contain very little logic, it will still have the potential to contain a huge amount of bugs of various kinds.

What's the current state of the art in testing the view itself?

Thanks Tom

+2  A: 

This is always a double edged sword. I see it as attempting to grab the low hanging fruit and build from there.

In theory the MVVM purist would state that absolutely no logic exists in the View's code behind. Making use of Prism for instance can help alleviate this as well as other varying frameworks out there. So coming at it from this angle it begins to get to the point of no logic existing in the View...fair enough, are we then going to begin testing the bindings? You could, however depending on the sizing of the app what is the return on that investment?

What I think this boils down to is where do you draw the line? For instance, even if you are testing the View, you will most likely be hooking into the code, you're white box testing at that point. You then can argue the black box angle, that only testing without internal hooks is valid. You can see that it becomes a circular nightmare.

In general I have focused on the big ticket items and went from there, testing what was possible with the time allotted.

Think of it this way...with a UI you can begin this fiasco of testing the coloring on every button, along with the placement, etc... That's silly to me. Automate the bulk of UI testing at the Model, ViewModel, layer and if you so desire test the bindings of your View. Other then that I would suggest the ad-hoc manual effort every UI developer should be doing at their workstation.

Aaron
Yes, so actual UI testing will still in most cases will in many cases still boil down to a fairly ad-hoc process. It's a slight concern of mine that developers will write plenty of tests for their view models, then consider the app 'tested', and neglect actual testing of the UI. Even if there's no logic in it, there's still a huge amount of white-box things that could be wrong and require testing.
Tom Davies
Agreed, it depends on the organizational structure as well. The company I am at now is a large enterprise so they have varying layers of testing that takes place. From the developer, to the QA analyst...to an SA analyst...to random external audits performed against the varying tests which were deemed run. My personal feeling is that when building a UI there is a lot of interaction taking place with the UI during development. It is not as obfuscated so to speak as perhaps a back end module that is just going to get slapped into a larger system.
Aaron
A: 

WPF and MVVM doesn't change the process of testing an application's UI. It just radically reduces the number of defects you'll find while doing so, because so much of the stuff you'd normally find and fix during UI testing is now found and fixed during view model testing.

Robert Rossney