I'm starting a new WPF/Silverlight custom control project and wanted to do unit testing on this one. However I'm a little confused about how to approach this.
This control would be based on the same codebase for both WPF and Silverlight with minor forking using #ifs and partial classes to tame the differences. I guess I could write unit tests for WPF part with NUnit, MSTest, xUnit, etc. and for the Silverlight part with Silverlight Unit Test Framework but this doesn't sound very elegant to me. I'd have to either ignore testing identical code on one of the platforms and test only differing parts (which is not very trustworthy) or rewrite tests for 2 frameworks (which is annoying). Is this the right way to go?
I'm wondering if there's some guidance, articles, tutorials out there on how to approach this task. Any pointers?
I am hardly an expert in WPF and Silverlight, but wouldn't it be possible to write the tests using the same techniques as the production code (#ifs and partial classes as you said)?
I tried to use xUnit first but it was kind of complicated to make same tests work in xUnit and SLUT (different attributes, syntax, etc.)
Then I did some basic experimenting with MSTest and from very simple test it looks like you can successfully use MSTest for the WPF part and same code with some #ifs, etc. and SLUT for the Silverlight part. So I'll try to go this route and see how it works in real-world situations.
Related
I am currently developing for Silverlight 4.0 and after mostly creating class libraries with TDD in usual C# (before SL) I can say that my current process is way slower than I am used to. (I think this can be said about any UI code compared to library classes, but here I think its really serious issue for me.)
I am wondering what techniques can be recommended to increase SL development performance.
I am mainly concerned about hard to test code (from my POV) - MVVM & UI - what can be done to improve performance here, I am thinking maybe theres a way to use a smaller sandbox somehow and test/debug control behaviour outside of scope of whole application, its pretty clear to me that me running whole application to test whether a new dialog box works correctly isnt fastest way and I could improve performance if I had a way to test this dialog alone for example, and there are probably other ways I cannot think of that can be a solution too.
EDIT: 1)here is something that I found useful , for TDD there is now a project that allows console runner to run tests so you dont have to run silverlight tests in browser & can integrate in your build process LightHouse
2) found following page, it provides some idea about a possible approach one could use to test view:
http://fohjin.blogspot.com/2008/09/how-to-test-your-xaml-behavior-using.html
there is no magic beautiful way and this one can be utilized but having to name all controls for example is a must to get this to work which isnt very good often
Statlight for the build server.
AgUnit to allow resharper to run silverlight tests.
WebAii for automation testing.
I'm not a fan of SLUT, as to run an individual test you have to cut and paste its name, and it doesnt remember it until you let it run all the way through, which I rarely do if I'm debugging.
Have you tried to use slut?
http://archive.msdn.microsoft.com/silverlightut
she will do what you want and pretend she enjoys it
I am developing quite complex .NET custom control (40K lines of code) but have some trouble testing it.
I have done several sample projects demonstrating main features of the control, but one can test only small subset of control states and operations.
Unit tests are also useless, because of these problems:
tremendous number of use cases (e.g. describing "item selections" can take some 4 pages of specs)
many ways of doing the same thing (and also from user-code or GUI)
the control have many states a sub-states, and anything may not possibly work in every state
how to test design-time support?
I know this is a common problem of GUI testing, so I would like to ask you if there are any well-estabilished practices of testing custom visual components?
Thanks for any advice.
The main thing is to limit the GUI testing to a minimum, because it's the most expensive way to test. In 40K lines of code I bet 90% of code doesn't really work with the WinForm GUI elements at all. So most of it could be covered by unit tests, but this depends on the way you structured your code.
Things to consider:
SOLID principles, especially the Single responsibility principle (SRP) - instead of a couple of huge "God" classes, you should rely on a large number of small "service" interfaces & classes which only do one thing and do it well. You can write isolated tests for these and then assemble them into a larger picture once you know they work OK.
MVP pattern (Passive View actually): the WinForm GUI code should be only a thin layer (View), everything else should be in Presenters and the Model.
Presenter First approach.
I work on a relatively complex WinForms application and these patterns have never failed me.
As for GUI testing, I use UI Automation, but only for some standard cases. Everything else is covered by non-GUI unit testing.
I have done one full project using WPF, and have (at least) a pretty good grasp of the main concepts, like XAML, Databinding, and MVVM. We did everything "by hand"--we did not use an MVVM framework or third-party tools. All XAML was written by hand as well (no Blend).
The new project I will start in a few weeks is pretty heavy-duty Silverlight, and I'm looking to get up to speed as quickly as possible. However most of the articles I've read on getting started with SL focus on XAML and databinding. Since my introduction to these concepts is still very fresh in my memory, I can certainly understand why these tutorials would spend a lot of time on these subjects--the learning curve can be very steep. However these are concepts that I am already familiar with, and find myself having to wade through a lot of covered ground to learn anything new and compelling.
So what I'm looking for are advice on what I need to learn and understand to go from being a journeyman WPF'er to a journeyman Silverlight'er. This can be in the form of:
General Advice
Key Differences
Rules of Thumb
Resources/Links ("A WPFer's Guide to
Silverlight" would be perfect :)
Major Pitfalls/Things to Watch Out For
Thanks in advance for any insight.
Rob Eisenberg (creator of Caliburn and Caliburn Micro) has a series of blog posts that talks about porting a WPF application to Silverlight. This may give you some insight into some of the framework differences.
Day 1
http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx
Day 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx
Day 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx
Day 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx
Day 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx
Day 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx
Day 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx
Day 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx
Some other thoughts off the top of my head:
Binding defaults to One-Way
No DynamicResource
TabControl is fairly different
No ability to define implicit DataTemplates for types
No CoerceValue in Dependency Properties
Event routing is very basic
No built-in command structure. You have the ICommand interface, and ButtonBase controls have a Command property, though there's no class that implements the ICommand interface.
Missing x:Static, x:Type
All service calls need to be on a different thread than the UI thread. This essentially requires you to learn / implement async programming strategies. See here and here.
As was mentioned, it's a different framework so not all libraries are available to you. Example: there is no XmlDocument - you have to use XElement (which is arguably better, though even so)
The Navigation framework is totally different than WPF. Stay away from it. It will only cause you pain. ;]
Several of the Controls that you find in the core framework in WPF you'll find in the Silverlight Toolkit. Download it, you'll need it.
No built-in Triggers, though can use behaviors / actions provided in the Blend SDK (which essentially gives you the same thing)
If you need to interact with a database, it will have to be through services hosted somewhere, or through COM (which means Silverlight 4 OOB with Elevated Permissions).
I disagree with Kevin in that testing is actually fairly easy and all of the major testing frameworks and mocking frameworks support Silverlight. Where you run into issues is Code Coverage. The Microsoft Testing framework supports Code Coverage (Premium & above) or else you can use dotCover. I believe newer versions of nCover supports Silverlight though I'm not 100% certain. Use StatLight to run your Silverlight tests (regardless of testing framework) from the command line.
If you're not already using an IoC container pick one up. Autofac, Ninject, StructureMap, Unity, MEF. (Another bias of mine ;])
I would highly suggest looking into the available MVVM frameworks. This has cut down a significant portion of the framework code I typically have to write. The frameworks will probably only get you 80% of what you need, though that's 80% you didn't have to write yourself. I'm currently partial to Caliburn Micro, though most of the popular ones will give you what you need.
I'll add more if I think of more. Good luck in your journey!
I've really only done Silverlight for a real app...but one of my co-workers was a big WPF guy, and so I hear some of his gripes.
You're going to probably need to use a WCF service, etc., for asynchronous queries to your service/business layer
You're using a subset of the .NET framework, so you cannot include ANY of your class libraries as a reference, only Silverlight class libraries can be included. However, you can do stuff like having a 'link to existing file' in a silverlight library that links to a file in other libraries...as long as the code still compiles with only the reduced set. This is a bit of a maintenance nightmare, but if you are doing WPF & Silverlight with some of the same code, it will probably save you from a lot of replication. Make sure to make it a link to the file and not a copy of the file, or changes in one won't change the other.
Unit testing your ViewModels will not be as easy. Need to Moq your service and use a Silverlight unit testing project.
Some of the reduced functionality is annoying for WPF veterans.
I think our WPF guy complained about not being able to bind stuff like a CanExecute method as easily on his commands as he was able to do in WPF. He had to call the method directly from the command or something. (I've only gotten a chance to look at MVVM a little so far as I'm now on a different project :(, so not quite sure on that one).
Hope that helps a little.
Hi I've searched some other posts, but most of them assumed that people knew what they were doing in their unit testing, and frankly I don't. I see the idea behind unit testing, and I'm coding an silverlight application much in the blind right now, and I'd like to write some unit tests to kind of be sure I'm on the right path. I'd like to be able to use the SL4 vs 2010 silverlight unit test project template, to keep it simple and not use external tools. So what I need an answer for are questions like:
what are the methods of unit testing?
what are the differences between unit tests, and automated unit tests?
How do I meaningfully unit test in silverlight?
What should I be aware of while unit testing (in silverlight) ?
Also should I implement some kind of IRepository pattern in my silverlight app to make unit testing easier?
EDIT:
I will be posting useful links here as I explore this along the way:
Implementing MVVM in silverlight - http://community.infragistics.com/pixel8/media/p/91949.aspx
Mix10 MVVM talk - http://live.visitmix.com/MIX10/Sessions/EX14
Unit testing Ria apps - Link
PK's great resource: http://dotenetscribbles.blogspot.com/2009/12/unit-testing-dependency-injection-and.html
I have never used silverlight unit test project template. I have only used nunit to do unit testing in silverlight. So, I will leave that for someone else to answer.
As far as your other questions are concerned:
Unit testing should drive your design. Your unit tests are first users of your code. Your code is based on some expectation and unit tests verify that expectations are being met. Using MVVM pattern (as you are using silverlight), facilitates unit testing. The most important thing to remember is that you have to write testable code. And to write testable code, the most important thing to remember is to inject dependencies. For example, if your code makes a call to the db. You, can't have a unit test making a call to the DB. Instead, you will mock your data acccess layer. This is where concepts like mocks and stubs come into picture. I use moq for mocking in my sivlerlight unit tests. Another, important thing I follow which I think facilitates unit testing is single responsibility principle. Finally, treat your test code as production code, else your tests might give you a false notion, that expectations are being met. Your unit tests are code and hence can have bugs.
what are the differences between unit
tests, and automated unit tests?
I am not very sure what do you mean by this. Unit tests are an automated way of white box testing. You can have scripts which run all unit tests, every time you checkin any code in the repository. This can be part of continuous integration.
How do I meaningfully unit test in
silverlight
In silverlight, to facilitate testing you should use commands, instead of writing code in code-behind files. This allows you to simulate button click and other GUI events while unit testing. Using MVVM pattern along with commands, you can test all of C# code (not xaml), right up to UI (Converter, VMs, etc).
It is very difficult to mention everything in this one answer. I would suggest, you google for MVVM, commands in Silverlight, Martin fowler - mock are not stubs, mocking frameworks for silverlight, dependency injection
I download command behavior from web and have implemented in my silverlight project. Now I am trying to figure out how to unit test ICommand properties. I know lots of people are working on this, so if you have a good simple example of unit testing ICommand, please let me know.
Thanks
Dev
You downloaded an ICommand implementation from the web? And you want to test it?
I recommend downloading prism and taking a look at their implementation of ICommand. They also have plenty of unit tests in the Reference Implementation (RI).
However, usually we don't test the ICommand implementations very heavily. They either work or they don't. The idea is that Commanding allows us to have thin UI layers and then testable ViewModels/Presenters. The View Models and Presenters we do test heavily. It's like in ASP.Net MVC, we do MVC so we don't have to test the views*.
*- To be sure, views can still be tested, but I think most people are moving away from the button pushing/angle bracket testing of MVC apps.
There is an open source framework called Silverunit CThru, that sits on top of Typemock, that can help you we when unit testing Silverlight. It's a real unit testing framework (the original is more of an integration test system). Cthru contains components that let you test Silverlight controls like real unit tests.