Unit Testing in Sitecore is Not Scary
I was chatting to another Sitecore developer the other day about unit testing in Sitecore. The impression I got from the developer was that although they knew unit testing could be done, they felt it was quite cumbersome and difficult. Possibly the length of my previous series on unit testing in Sitecore didn’t help the cause either. So I’d like to show you just how easy unit testing in Sitecore is. One reason my previous series was so long was because it covered a lot of topics and areas related to unit testing and how to test various UI components in Sitecore as well as different strategies for setting up and pulling down your test data. Unit testing of UI is not as important as unit testing of business logic and utility methods. These are the easiest pieces of any system to test and it’s where you should spend you initial time, especially if you’re trying to introduce unit testing on your projects for the first time. Your UI components would need testing though if they themselves contained a level of business logic. And I’m not talking about heavy business logic, more the things like altering or filtering the output based on parameters passed to your component (especially relevant for XSLTs). So I’ve recorded a video showing exactly how to setup unit testing on your Sitecore project using my custom NUnit test runner. I’ve found it much easier and safer to use this custom test runner rather than trying to fake the HttpContext or mocking. I’m a strong believer that you shouldn’t try and mock something unless you have intimate knowledge of the component being mocked and can have it changed if it doesn’t meet the assumptions your tests and mocks were built around. Mocking an entire system such as Sitecore or SharePoint is fraught with danger and it’s likely that you think you have a good idea about how the system works, but you don’t have the ability to change it if an assumption you’ve baked into your mock is wrong. Part of the unit tests running inside the system is to validate your understanding of the system. The process I show in the video is:
- Download the custom test runner
- Include the test runner it in your test project
- Configure the build using MSBuild
- View the test runner
This is probably the simplest form of unit testing for your Sitecore projects.
https://www.youtube.com/watch?v=mZKSl3pemEs
You can download the custom test runner I use in the project from the codeflood website. In the next video I’ll show how to start writing your unit tests.
I'm not sure that I'd call that easy. You need to know a (some-what) obscure MSBuild syntax and it is also not able to be included as part of a CI process since it runs in-browser (or so is implied by your video).
Limiting your unit tests to only being run on each developers machine, and not part of a CI process is not really a good idea, as you're CI will be able to produce failing builds without you being aware.
For unit testing applications which rely on the HttpContext (as you're referring to) I find it's much simpler to use MSTest and have it kick off cassini. You can then test those APIs as the HttpContext is available (it's what we did with the Umbraco 4.5 release).
But in reality I'm much more of an advocate of using an abstraction layer. Say for example you have a static object which comes from your underlying framework (aka Sitecore) I would create an interface or abstract class (depending what's best in the scenario) and then pass that into the user control (well really I'd use WebForms MVP and have a DI framework wiring up the dependencies but covering that in a comment isn't a good idea :P).
This way you can write a unit test that runs through a test running (like NUnit) without needing the HttpContext at all.
Just my $0.02AUD