A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really wanted to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.
Check out part 1 Secure By Default and part 2 Three-way Data Access.
A topic which is very near and dear to my heart is testing. For a number of years I've been thinking about and trying to implement unit testing and test-driven development in Vertica but only recently have we been making progress on that front. Why then has it taken so long to get going with test driven development and unit tests in a shop where a lot of dedicated and enthusiastic people work?
The reason is simple: We' do most of our work on Microsoft server products like Commerce Server, Office SharePoint Server, and BizTalk and those products are not very well designed with regards to enabling unit testing scenarios. Now this post is entitled developing with Microsoft Commerce Server so naturally I'm going to focus on this.
Test driven development and unit testing require a lot from your architecture to make it work. In order to do effective unit tests in a system we need to able to divide the system up in just that, units. I'm not going to delve into the aspects of unit testing techniques here as that topic alone would require numerous posts to cover but suffice it to say that interfaces play a import role in enabling the scenario, class inheritance does as well.
Now how does this relate to Commerce Server? It turns out that you're going to have to look long and hard to actually find interfaces to enable mocking. Everything in Commerce Server is a concrete class, in some instances even classes which have a natural relationship doesn't share a common interface or even a base class which hampers our attempts at creating structured tests.
When developing with Commerce Server the Adapter pattern will become your friend, simply create an adapter for a particular piece of functionality in Commerce Server and work off of that instead of the real API and you're set. Unfortunately this means extra work for you as the developer if you want to create proper tests for your solution.
A lot of the functionality of Commerce Server is accessed via a class called CommerceContext, this works in much the same way as the HttpContext we know a love. Unfortunately it's heavily reliant on HTTP modules to initialize it thus making it tough to test. As a Commerce Server developer it's natural to go to the CommerceContext and access the various subsystems form there. Doing this however tightly couples you to HTTP which is a bad thing if you need your logic in a different context like say for unit testing. The remedy is simple but you need to be aware of this fact otherwise it will bite you in the ass at some point. I did a post on working with the profile outside of the ASP.NET context back when I was working with Commerce Server 2002; it just so happens that this particular technique is still viable today.
The bottom line with respects to structured testing in Commerce Server is that we're faced with many of the challenges we see when working with legacy code which has not been designed specifically for unit testing. By no means does this mean that it's impossible to do unit testing with Commerce Server; it does however mean that you need to be aware of the fact and design your architecture accordingly and that there will be areas which you won't be able to touch with your automated tests.
Developing with Microsoft Commerce Server 2007 Part 4: Magic Strings Galore
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.