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.
Related
So i found a good tutorial on silverlight unit testing however it doesn't address issues like styles not being present when you instantiate a page, which throws an error and crashes the test am i supposed to setup a complete cloned environment like adding in the styles, service references, images, etc into the unit test project?
You've ran into an issue that has plagued software developers for many decades now - how do I test UI? The simplest answer is - don't. This is a generally accepted practice. Instead, design your application such that most of the logic is outside of the UI and built into components. You can then also design your UI logic of the application using patterns such as Model View Controller, Model View Presenter, and Model View View-Model which allow that logic to be tested. XAML based technologies typically lean towards the MVVM pattern.
Here is an intro to MVVM by Jeremy Likness:
http://csharperimage.jeremylikness.com/2010/04/model-view-viewmodel-mvvm-explained.html
I'm currently using the Silverlight Unit Test Framework, but I'd prefer to run tests directly in VS2010. I'm curious to know what approaches and tools everyone else uses.
I'm using Silverlight 4 with Prism and the MVVM pattern, and I'm specifically interested in integrated Silverlight unit test support in VS 2010 that I can use with my ViewModel unit tests. I'm using dependency injection with Unity, and I am writing unit tests by mocking the calls in my WCF layer using Moq for Silverlight. I am not even looking at integration tests at the moment, but even in a simple unit test which tests a single ViewModel command, the service request to my mocked service layer can take around 50 milliseconds. Therefore support for asynchronous tests is important to me.
The issue I'm raising here is not related to View testing, which I have handled with some success in the past using System.Windows.Automation.Peers, and - although I have not used it yet - could possibly now handle more easily with the support in VS 2010 Feature Pack 2 (which appears to be targeted at automation / playback of UI tests from what I gather).
I should mention that my findings from the products I've looked at and used so far are as follows:
Silverlight Unit Test Framework - I currently use this, and it's great as far as it goes, but its limitations are (a) it is not integrated with Visual Studio; and (b) if you don't want to run all tests, you are limited to the crude tag expression filter.
StatLight - very nice. I currently use this, and have used it since v0.9 when targeting Silverlight 3 on a previous project. Being a command-line tool, it can be integrated with a continuous integration server - which certainly handles another required scenario. But it is of no use directly in terms of Visual Studio integration during the development process.
Unit Test Result Viewer for Silverlight (Visual Studio extension on the Visual Studio gallery) - looks promising, but its limitations are (a) currently fails to find projects which are located in solution folders, rather than under the solution root; and (b) runs all tests in a given assembly (via StatLight), with no apparent ability to run a specific test, or a selection of tests.
Einar Ingebrigtsen's Silverlight Unit Test Runner for ReSharper, which later became Odin - ahead of the game (it first appeared in 2008), but the limitation is that it appears that this project is no longer maintained (most recent update is Apr 2009).
AgUnit ReSharper plugin ( http://agunit.codeplex.com/ ) - looks excellent initially. After downloading the source code for it and building the latest (bug-fixed) version to work against ReSharper 5.1, I was very encouraged. But unfortunately it does not handle asynchronous tests. This is a design limitation with the threading, so it does not matter whether you try to use the asynchronous support that is built into Silverlight Unit Test Framework (Microsoft.Silverliht.Testing.SilverlightTest base class), or whether you're using AutoResetEvent or anything else. This has been noted by the coordinator on the project's discussion forum on CodePlex. This is a massive limitation.
TestDriven.NET 3.0 - appears to have support for Silverlight 4.0 tests at first glance, but the limitation (I suspect) is Silverlight 4 "assembly portability" (i.e. the 5 dependent assemblies that are portable between SL4 and .NET 4). Certainly, when I tried using it with a simple POC, it crashed my instance of VS 2010.
Perhaps I've missed something here - I wonder if anyone in the community has any better ideas for Silverlight unit testing?
I use the Silverlight Unit test framework, AgUnit, and RX with a mock IScheduler provider to make my unit tests single threaded :)
UPDATE:
I'd already settled on using StatLight for my continuous integration server, but I was looking for a solution to allow me to run asynchronous Silverlight unit tests directly in VS2010 during development.
Inspired by Rob Fonseca-Ensor's suggestion to use Rx (see his separate answer on this page), I took another look at the issue. That led me to find a non-Rx solution to the problem of using AgUnit to run async Silverlight unit tests.
The solution I think I will use - at least for now - is the combination of:
Silverlight Unit Test Framework
ReSharper 5.1
AgUnit ReSharper plugin
[Mock async pattern]
My ViewModels have bespoke service classes injected into them which provide abstractions of my (auto-generated) WCF service reference classes. To help provide access to the WCF service methods, my bespoke service classes also rely on another common class which wraps the async pattern. For my unit tests, I was already mocking my WCF service reference classes and my bespoke service classes with Moq - but I hadn't looked at mocking my async pattern wrapper class.
So I decided to mock my async pattern wrapper class as well. The attraction of doing this was that I thought I might then be able to use Rx with a mock IScheduler (as Rob suggested in his answer) in all my mocks, while leaving my real classes free of any references to Rx (which is a requirement because for this project at the place I'm working, I need to keep Rx out of any code which gets deployed to a production environment). However, once I'd mocked the wrapper class, I realised that I didn't even need Rx, and that there was an even simpler solution - which I should have really looked at before. It's pretty trivial - all I really needed to do was mock the wrapper class and ensure that it called Invoke on the callback operations, rather than calling BeginInvoke. This ultimately prevents the callbacks which work fine when running under the Silverlight Unit Test Framework in a browser session from going into a black hole when the unit tests are run by AgUnit within VS2010. (Allowing the callbacks to go into black hole when using AgUnit would of course have prevented the individual tests from completing properly, and could have led to either timeouts or - worse still - false positives in the test results.)
In the absence of better advice from any subsequent answers to this question, this appears to be the easiest way for me to handle this scenario - allowing my async unit tests to run in AgUnit without requiring Rx in my production code.
For anyone else not facing company-imposed restrictions on deploying code that uses Rx (which is still a DevLabs project) to production, I think Rob's solution would definitely be worth looking at.
I'm the author of the AgUnit plugin.
AgUnit blocks asynchronous unit testing to speed up the test run. Under the covers it uses the same code as the Silverlight Unit Test Framework test runner, but this runner is very slow if you have to handle a large number of tests. I've seen differences between almost half an hour and a few minutes for a couple thousand tests.
That said, if you do want asynchronous testing, it's a very isolated part of AgUnit that does this. I'll try to create a build with it disabled. In the future this will be a configuration option or an attribute, I've not decided yet.
Feel free to contact me with any questions or requests.
I usually create a normal unit test project in VS.NET, add my Silverlight assembly in references and write unit test classes.
So everything works out of the box. What's a problem with this solution?
Have you read about the recently released Visual Studio 2010 Feature Pack 2. Currently it only accessible to MSDN subscribers, and it only works with certain editions of VS2010 (Premium, Ultimate and Test Pro).
Here is a quick overview: Link
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'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.