Thanks to everyone who attended my presentation on Unit Testing Dynamics CRM Plugin and JavaScript code hosted by http://www.xrmvirtual.com/. I’ll update this post when the recording is available. However, the webcast was basically a shortened walkthrough of these two posts:
…with some additional “what is and why unit testing” commentary.
Here’s the presentation:
UPDATE: Fixed the video resolution issue. Higher resolution (720p) version is available.
After writing my post on unit testing plugins, I’ve been asked a few times about how to do the same for Dynamics CRM 2011 JavaScript web resources. While I knew it could be done, truth be told, I had never done any significant JavaScript unit test using Visual Studio other than unit testing Script# code using MSTest (the default unit testing framework in Visual Studio). Sure, I had played around with QUnit. However, QUnit is one of those JavaScript testing frameworks which requires tests to run within a browser. What I wanted was an approach which met the following criteria:
So I scoured the internet, tried a bunch of things I came across, and finally landed on approach which combines lessons learned from the following resources:
While the catalyst for this video was to demonstrate JavaScript unit testing in the context of Dynamics CRM 2011, the approach can be applied to any scenario where you are using JavaScript and some additional API (SharePoint, standard web app, etc.).
Just like with my post on unit testing plugins, it is not my goal here to convince you that you should embrace unit testing. It’s for those of you who have already bought into the value of unit testing, want to apply it to JavaScript web resource development, and do it in a way that meets my stated criteria above. In the video, I assume you understand concepts like mocks, fakes, etc.
You can grab the finished example I show in the walkthrough here:
Hope this helps those of you who have been as eager as I have to unit test JavaScript web resources.
This is probably the most promised, but never published blog post on my list of potential posts. I’ve managed to convince enough CRM developers I’ve run into that they should get some test driven development with unit testing religion. Especially because of the added productivity benefits for CRM plugin development. This post isn’t to convince you of the benefits of unit testing. There are plenty of articles/blogs which cover that topic just fine. I’m not interested in debating the virtues of unit testing. Love it or leave it;).
The purpose of this post/video is to show you how I develop and unit test plugins. There are a few articles out there about how to unit test CRM 2011 plugins. I haven’t been satisfied with the approaches I’ve seen. I landed on an approach which combines using the CRM 2011 Plugin Testing Tools for mocking IServiceProvider and Moles fore detouring types used inside the plugin which are difficult or time consuming to mock such as OrganizationServiceContext, Web Service calls, and others.
You can grab the finished example here:
You can also grab the starter solution I mention in the video here:
Once you’ve learned the basics in the video, hop on over to the series below for some more advanced examples:
http://zhongchenzhou.wordpress.com/2012/07/08/dynamics-crm-2011-unit-test-part-1-introduction-and-series-contents/
The series above focuses on using Fakes in VS2012. Fakes is the successor to Moles. However, the general techniques still apply whether using Fakes/Moles. If you are using VS2012, then use Fakes. If you are using VS2010, then use Moles.
I find many people who are new to unit testing have questions about where it fits in relation to other forms of testing. Unit testing does not replace other forms of testing such as integration testing (i.e. testing the plugin running in CRM). TDD through unit testing is an upfront developer discipline. It requires a certain culture and mindset on a dev team. In my opinion and experience, it helps me produce better code and allows me to catch more (not all) bugs early on, before handing things off to other testers. It also makes the others testers lives/jobs easier.
When applying this approach to CRM plugins, there’s a bonus side effect that (for me) allows me to be more productive in authoring my plugin code because I can:
As part of building my WP7 app, I spent a fair amount of time trying to get code coverage working for my unit tests. I tried a number of different approaches including using the Silverlight Unit Test Framework and NUnit + dotCover. I finally landed on an approach that worked for me using the unit testing capabilities in Visual Studio 2010. Since this is a much confused topic with very little info on the web on how to successfully get working for Silverlight/Windows Phone apps, I published a screencast on the subject. I hope you find it useful.
Direct link:
https://channel9.msdn.com/posts/Code-Coverage-for-Silverlight-and-Windows-Phone-ViewModels
From http://en.wikipedia.org/wiki/Code_coverage:
"Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested."
In this screencast, you will learn how to get code coverage for your Silverlight and/or Windows Phone ViewModels through unit testing. You can learn more about code coverage in Visual Studio 2010 from:
http://msdn.microsoft.com/en-us/library/dd537628.aspx
Gold Coast 