We have talked about how to set up your test environment, how to write tests and what to do with the freedom that the test give you (write code that is clean). Now we start to get into the nitty gritty of being a code cleaner, we need to start to clean some legacy code. I’m young, so probably my experience is not the same as most professional code cleaners, but when I think of legacy code, I think of sharepoint programming.
Programming with sharepoint is hard, you need to know how to work your way around many weird behaviours is sharepoint like the fact that in a field XML schema False != FALSE.
But you get used to that stuff. The biggest problem with sharepoint is that it wasn’t built with the idea of enabling testability. No, most interesting classes are sealed (can’t be extended), and a value that can be approximated with 100% of the classes doesn’t inherit from an interface. You have to pass around concrete classes all around your code. This is a problem because you can’t replace an SPListItem with a test double. And to make matters worst, the biggest advantage of using sharepoint is also its biggest testability problem. Sharepoint is a monster, it has every functionality you could think of: CMS, Document management, Search, OCR, Cache, line of business integration, social netnork, blog, forum, ecc. It wants you to use its features, it wants you to integrate with it, but if you do in a naive way you are lost. There’s no way you will be able to TDD your application.
Luckily there’s a better way, its hard work, specially in the beginning when you need to change your frame of mind and the way you work, but there’s a better way, and I’m here to guide you.
We will start with a brief detour talking about a building block, the repository pattern, then we will see:
- How to test your repositories
- How to test your business logic
- Sharepoint tdd tips and tricks
- Why remote provisioning helps
- How to do remote provisioning
- Building repositories with SPMetal
- More ways to isolate from the framework