Stop doing TDD and start doing BDD with SharePoint!

I’m certainly one of those guys that like to do TDD and If you ask people what differentiates me from other developers you will almost certainly get the answer that I’m really serious about quality.  

But after my last project I’ve been become “wiser” or more careful with what kind of tests to use when and where. So why the unusually provoking title?

Last week I got a tweet from my friend Johan about tips on how to do TDD in SharePoint with assemblies that reside in the GAC.Stop doing TDD and start doing BDD with SharePoint

For a brief second I thought that I would just give him a list with the different methods/hacks/workarounds I’ve seen and then I thought:

“you’re only fighting the symptoms, we deserve better”

SharePoint lacks good mockable Interfaces and serves you with lots of sealed classes and static classes. That’s not a great foundation for TDD.

Furthermore we have the whole GAC thingy, also not a great foundation for TDD. If only I would have received a euro for every time someone in my last project asked me why the tests were not passing and whereby I asked “do you have an older assembly in the GAC?”

I can’t see how trying to do TDD in SharePoint will lead to anything but workarounds or hacks to get it working.

Another aspect of truly doing TDD is that you really need a vast knowledge of the domain and IMHO very few developers doing SharePoint development have the necessary knowledge.

In fact I did a test with two groups in my last SharePoint project. Both groups were told to TDD a small Document Set feature. Both groups were given 1½ hour. I coached the second team and 5 min into the exercise I told my group that let’s skip TDD and just do the feature.

The result was spectacular as you might have guessed. The first group almost didn’t make any progress at all and the second group didn’t come very far either. Why? Not enough knowledge of the domain and no mockable interface makes it almost impossible to do TDD in my opinion.

Still not convinced? Well it’s a free world go ahead, try it, fail and become wiser yourself.

I’ll even give you some methods I’ve used/seen/hacked/worked around the last couple of years (without any specific order of importance):

  1. Set Assembly version to 1.0.0.*, this way you won’t have any issues with the GAC thingy. But you’ll have lots of other side effects that you need to mitigate/automate.
  2. Retract dll’s in test setup/teardown.
  3. Write you class under test in the test project and then move it. Johan wrote about a great spin-off on this method here.
  4. Wrap SharePoint artifacts with your own Interfaces.
  5. Separate your domain from the infrastructure, and TDD the domain object only leave the infrastructure alone!
  6. Use a mocking technology like Fakes/Shims/Moles/TypeMock. This demands a really deep knowledge and understanding of SharePoint so if you think this is something you’d like to try, I say beware you’re treading in deep dark waters.

What you should do instead is to treat SharePoint as the framework it is much like the way you would treat the .Net Framework.

BDD is a nice way to do this, you invest more time in designing behaviors or capabilities of your application using SharePoint as one of those capabilities.

But that’s just my very personal 2  cents,


End to end TFSBuild pattern for BizTalk 2009, part 3 (Commitment)

So you thought that I would give away the secrets this time huh? I’m just kidding it will all be revealed soon in the last part of these series.

Anyway, how come I make this artistic pause? Anyone? Let’s begin with some basics:

  • Automated builds or continuous integration is useless if the team using it isn’t committed to solving problems with the builds and/or maintaining the builds.
  • Visualize the status of your builds on digital boards, flat screens or with emergency lights/sounds and make sure everyone in the project knows the status of the builds.
  • When all builds are green and all tests are green in your project you are in what I call a normal stage. In a normal stage you should make time for small improvements throughout your team i.e. refactoring, code reviews etc.
  • If any builds are red or any tests are red in your project you are in what I would call a deviate stage. In a deviate stage you should really work as a team to solve the deviations and most importantly learn from it and finally make improvements in how your team works.

Is your team committed to these basics? If not take a good look at the benefits of automated builds:

  • Always the same automated way of compiling, building and deploying your codebase.
  • No more manual releases.
  • One single location for the compiled binaries i.e. the drop folder. Make sure that all deployment flows from the drop folder i.e. establish one deployment method that uses the contents of the drop folder and use it on every environment starting with your own every morning.
  • Automated regression tests.
  • Intact source tree
  • <Enter a clever reason here>

Still not convinced? Well then you should really visit a dev shop where they’re committed to this and compare their speed, quality, agility and team spirit to your own; and I’m sure you will get inspired.

Au revoir


End to end TFSBuild pattern for BizTalk 2009, part 2 (Tools)

Ok, you finally got your build environment installed and tested with a simple Hello World build and you’re ready for the next phase.

Before I show you the good stuff J there is some tools that you need to succeed with this quest:

  • You’ll need basic knowledge of MSBuild and TFSBuild or you could copy and paste my build pattern if you like J
  • I mainly use the OOB tools that come with .Net framework and BizTalk i.e. BTSTask, BTSWCFServicePublishing and GacUtil with my builds because I find them to be stable, supported and generally well documented.
    These tools should already be installed in your environment but you’ll have to make sure that you have the correct permissions on your TFSBuild service account to use them.
  • I use BizTalk MsBuild Generator to start and stop BizTalk applications so you will need to download the tool and extract BizTalk.BuildGenerator.Tasks.dll and BizTalk.BuildGenerator.tasks. These two files are then placed under source control with the teambuildtype.
  • If you need automatic generation of the BizTalk binding-files from a template (for different target environment for instance) I have found the XMLPreprocess tool very helpful.
  • In the early years I used the SDC tasks but it’s no longer supported but there is still a lot of good stuff in that package if you want to learn MSBuild in more depth. The replacement is called MSBuild Extension Pack if you want to check it out. While you’re at it you should really checkout MSBuild Explorer.

Try to install the tools in a common directory i.e. C:\BuildTools or something similar and keep these tools under source control at all time.

Until next time have a good one!