Ok, so MVVM is obviously about Unit testing right? Well, I don’t really agree, but it is definitely a part of why you chose MVVM, even if it is only a small part of the reason for me. I have been using the MVVM pattern for a while now, but I still haven’t started unit testing my code properly. I know I should, but for different reasons I never get around to it. Mostly due to time constraints.
And for all of you that tell me that writing unit tests will not take more time as there will be less bugs to fix, bug off! It does take time. It does include mocking or stubbing services. It does take time to figure out how to write useful tests. And first and foremost, it takes time to get the experience needed to do it fast… So argument ignored!
What I do do though though, is keeping it in my mind when I design my VMs. I always consider whether or no the VM is testable. If it is, then I know that I haven’t introduced any dependencies that I shouldn’t have. And even if it isn’t a fool proof way of limiting dependencies, it does help me…
I am currently working on a larger OOB application that might live on for several years and is built in a modular way using PRISM. So even after I am done with it, the application will evolve and progress, and for something like that, I find that having unit tests for the VMs seems like a very good idea. It makes you think a little extra, and verifies that you aren’t breaking things down the track.
So how do you do unit testing in Silverlight? Well, luckily there are solutions to this in the “Unit Test Framework for Silverlight”, which has now merged into the Silverlight Toolkit. So if you have downloaded the Toolkit, you are all set to go!
If you start a new project in VS2010 after the install, you have the option to create a “Silverlight Unit Test Application”. This is a small application that is prepped and ready to test your code.
So why is it an application instead of just a class library? Well, all Silverlight code must run inside the Silverlight runtime, which means it has to be run in a Silverlight application. You cannot run the unit tests as you normally would by using a “harness” inside CS, as it needs to spin up a browser and run the plug-in to be able to run the tests as they are Silverlight tests. This has some major drawbacks out of the box, but I will show you how to get around that… The biggest drawback is the fact that you get the results displayed visually in the browser, making it hard to integrate with CI for example.
But let’s hook everything up and have a look at it…
When you create the application, you get a simple App.xaml file as well as a test class. In the Application_Startup method in App.xaml.cs, you can see that it hooks up everything that you need to run unit tests, which isn’t really that much. It sets the RootVisual to the result from a single static method call called UnitTestSystem.CreateTestPage(). That’s it… That will hook everything up for you. It will create a control that hosts the test and run them for you.
The test class in turn looks like any other test class more or less. The class is adorned with a [TestClass] attribute, and the test method with a [TestMethod]. These are standard attributes for unit tests from Microsoft.
Read more: DarksideCookie
And for all of you that tell me that writing unit tests will not take more time as there will be less bugs to fix, bug off! It does take time. It does include mocking or stubbing services. It does take time to figure out how to write useful tests. And first and foremost, it takes time to get the experience needed to do it fast… So argument ignored!
What I do do though though, is keeping it in my mind when I design my VMs. I always consider whether or no the VM is testable. If it is, then I know that I haven’t introduced any dependencies that I shouldn’t have. And even if it isn’t a fool proof way of limiting dependencies, it does help me…
I am currently working on a larger OOB application that might live on for several years and is built in a modular way using PRISM. So even after I am done with it, the application will evolve and progress, and for something like that, I find that having unit tests for the VMs seems like a very good idea. It makes you think a little extra, and verifies that you aren’t breaking things down the track.
So how do you do unit testing in Silverlight? Well, luckily there are solutions to this in the “Unit Test Framework for Silverlight”, which has now merged into the Silverlight Toolkit. So if you have downloaded the Toolkit, you are all set to go!
If you start a new project in VS2010 after the install, you have the option to create a “Silverlight Unit Test Application”. This is a small application that is prepped and ready to test your code.
So why is it an application instead of just a class library? Well, all Silverlight code must run inside the Silverlight runtime, which means it has to be run in a Silverlight application. You cannot run the unit tests as you normally would by using a “harness” inside CS, as it needs to spin up a browser and run the plug-in to be able to run the tests as they are Silverlight tests. This has some major drawbacks out of the box, but I will show you how to get around that… The biggest drawback is the fact that you get the results displayed visually in the browser, making it hard to integrate with CI for example.
But let’s hook everything up and have a look at it…
When you create the application, you get a simple App.xaml file as well as a test class. In the Application_Startup method in App.xaml.cs, you can see that it hooks up everything that you need to run unit tests, which isn’t really that much. It sets the RootVisual to the result from a single static method call called UnitTestSystem.CreateTestPage(). That’s it… That will hook everything up for you. It will create a control that hosts the test and run them for you.
The test class in turn looks like any other test class more or less. The class is adorned with a [TestClass] attribute, and the test method with a [TestMethod]. These are standard attributes for unit tests from Microsoft.
Read more: DarksideCookie