Unit Testing in Sitecore is Not Scary

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

OK, granted, perhaps I made it look harder than it needs to be because of my use of MSBuild. I use MSBuild to maintain a strict separation between my code and the system I'm developing into. After all, I'm only using it to copy some files around after the build, and you could actually do that with some simple bat commands (not quite as elegant) or just dev directly in the same folder as Sitecore (again, not quite as elegant IMHO).
The CI considerations are a good point. I've been thinking about updating the test runner to have some kind of XML interface to allow calling from a program (other unit tests perhaps?). I'll have to explore your Cassini approach to see if I can make it work. And although CI is important later on, the initial hurdle is to get devs writing tests. Baby steps.
In terms of the abstraction layer, it feels a little heavy for a simple content system. If you're developing a large web application then it sounds like a very good idea, but abstracting away the system for a basic content website feels like a lot of work (especially in a very competitive market).
Thanks for your feedback Az, I'm looking forward to seeing your blog posts on everything you mentioned above (particularly MsTest with Cassini and hooking that into CI) :)

Still struggling to get CI and testing going? Bloody hell I was trying to get that started when I use to work with you. Get your act together boy :P
I disagree that creating an abstraction layer between your data store and your business logic is overkill, and that's what you're testing right, interaction between a data store (in this scenario Sitecore) and business logic, not interaction between the data store and the UI (accessing a field and putting it into a label)? Right?
Creating a separation of concerns layer means that you actually have to think more about why you're interacting with the data store (or any sub-system) more than going "lets just grab some data". It can help you identify commonality between API calls (if I need to access data X and you need to access data X let's have a single method we can both use), where as if you're writing Sitecore.Some.Api.Method.Access.Data["blah"] it's not as easy to pick up.
At TheFARM we never exposed Umbraco to our Web project, we always had a middle tier (with the exception of when you just wanted to use then you use the Umbraco API, but that's not something you'd unit test anyway ;)) and although it seems excessive the first time the second time you do it it makes sense and the third time you get shitty when it's not already setup for you.
If you ever were on IM programs it'd be easier for me to berate you than in your blog comments :P

Is it lonely all the way up there on your pedestal Az? :)
Ah, I get you now. Yes, I agree. In fact, I normally try to do what you've described in that the UI project shouldn't access Sitecore directly but should always go through a business layer project to get the data it needs. If you also abstract your data engine (Sitecore, Umbraco, SharePoint, whatever) away from your business logic code then you can use whatever unit testing framework you like cause your business code shouldn't rely on HttpContext.
The method I show in the video and will continue in the next video is testing that data layer, where you can't run without HttpContext. At the start of the video I showed a data method I'm going to test that should get a list of filtered data items. This is the case you need the custom test runner cause you can't avoid or abstract the CMS API away.
And why do you think I stay off the IMs :)

My pedestal gives me a good view of the landscape :P.
The issue I have with what you're talking about is that you're testing something you don't have control over, you're testing that the Sitecore.Context.(and so on) returns data in the format you expect (and/ or require). But what if it *doesn't* work as expected? How do you resolve that? You can't change the Sitecore API...
What you're showing here is not unit testing, but instead its integration testing, so that "with data api A I get data B and it should do X", where as the unit test should only do "for data B (from any source) it should do X".
You should never have expectations on a system you can't control in a unit test ;)

It would seem we've come to a consensus. I agree. By definition what I have shown in the video is not unit testing, it is integration testing as this style is all about calling the API of that external system which you have no control over. I used the term "unit testing" as a general term as developers understand what they are. As you'll see in the next video I'm not testing the Sitecore API itself, but my business logic which uses the API.

Just like an old married couple! :)

Yes, but I'm the man in the relationship :)

[...] finally found enough free time to record the continuation of my first unit testing in Sitecore video which showed how to add a test project to your solution which used the codeflood custom NUnit test [...]

[...] Deneys blog on unit testing with Sitecore using a custom test runnner can be found here.How to change config files to work with Sitecore without a “context” here. By Mike [...]

I agree with Powell about putting sitecore in a data-access layer and then using a test-double for it. Been there; done that. But I will say you're right about the heaviness as well. For those just learning sitecore (and maybe tdd) it can be enough to kill the testing all together ...

Hello, Late to the party! Just trying to find a good approach for unit testing Sitecore (in a large and largely un-unit-tested project) and came across this post and conversation. Just wondered if/how you can enable Page Editor if you’re abstracting away the Sitecore gubbins from the UI? Thanks, Owen

Thinking about it/Googling – I’d probably use Glass.Mapper.

[…] and read Alistair Deneys’ blog post Unit Testing in Sitecore is not Scary […]