« Measuring velocity is not enough
Small steps for testing, big steps for SharePoint testing »

Tuesday, June 23rd, 2009

TDD and SharePoint is it worth doing?

Posted in Agile, SharePoint, Testing  |  Comments


Just read a post by Sahil Malik where he gives his reasons for saying

TDD + SharePoint 2007? Well – screw it! Not worth it IMO.

The reason for his statement is that he sees the actual C# code developed as being a very small % of the total SharePoint project and the effort to do this as not worth the return when you consider the project costs overall.

The problem is, like so many people, he is getting TDD mixed up with doing good development.  He dismisses TDD because it is harder to do in SharePoint because of the API.  It’s not TDD that makes it harder,  it being able to isolate the API and design testable code that is harder.

If you listened to the SharePoint Podshow I did with Eric Shupps we were in agreement that what actually mattered was that you developed good quality code,  that you had the processes in place to enable code reviews, unit testing, integration testing, and the like, that all go together to ensure the code you do develop for your SharePoint solutions is Enterprise ready.

I hold my hands up, I do talks on TDD and SharePoint.  I don’t do this because I think that everyone should do this on day one,  I do it because people have used SharePoint as an excuse to not doing quality development.  The comment ‘we can’t do unit testing because we are using SharePoint’ has been common among development teams,  other just don’t do unit testing anyway so it never even cropped up.   So if I can demonstrate the you can go all the way and actually code your solution using a technique like TDD then this argument no longer holds water.

What the question should be

Quality Development and SharePoint, is it worth doing?

And the answer to that is a big Hell Yes!

And if your happen to use TDD to write some of that quality code, then that’s good too.

The key thing to remember is that you need to make a judgement call about the value; in Sahil’s defence he did mention this.  What I can’t take is that he adopts the ’screw it’ stance before he even starts. This to me is a much of a problem as the people at the other end of the spectrum that think you can ONLY code using TDD.

This entry was posted on Tuesday, June 23rd, 2009 at 4:41 pm and is filed under Agile, SharePoint, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • HELL YEAH!
    Oh sorry about the brute vocabulary.. What I meant to say was: I love TDD with SharePoint, thanks for providing us with awesome insight Andrew.
  • There is TDD similar to how the P&P SharePoint group shows. But where I really have a hard time with TDD and SharePoint is where it relates to workflow. Sure I can make workflow act like a simple controller delegating out to other code, but doesn't that start taking away all of the value of workflow? Or is that the real value, workflow is supposed to only be a broker? But then how do you test logic in the workflow? After all there is an if command.
  • Aaron,

    TDD == an approach to writing your code that starts with the unit test first.

    What you are talking about is the scope of the unit tests, in the P&P project they make a call as to which elements of the code base are demeed appropriate for unit testing.

    The problem you have with unit testing workflow code is that workflow is basically (or predominantly) infratructure and in order to unit test your code you need too mock out/fake way to much in order to make it a Unit Test work. This is why most projects adopt automated integration testing to prove the workflow code but these can take a long time to run. This is definately an area that I think could do with further investigations and guidance.
  • I don't think anyone would disagree with the statement that quality development techniques should be used within SharePoint projects. Certainly no one believes you can forego code reviews or testing. However I think the point that Sahil was trying to make was that within the context of the typical SharePoint project, the benefits of TDD in particular may not warrant its additional costs.
  • Ryan, the problem was totally with Sahil's point about TDD.

    You agree we can't forgo testing, and here we mean unit testing as well as all the other kinds. The cost of producing the unit tests will be similar whether done with TDD or done afterwards (many argue that with TDD it will be less).

    Why then would Sahil want to make such a big thing about a specific developer approach to the generation of testable code? As I stated above I think the problem comes with peoples lack of understanding regards to TDD and also the sometime evangelical preaching that some in the community do for its use.

    Now the question of how much code do you unit test and if you would be better servered through the use of more Integration tests and automation is a valid point. And you will find that in SP projects (like the ones Sahil refers) there is likely to be a different mix of unit/integration tests.

    But this is nothing to do with TDD - hence my post.
  • Joe Chung
    How do you do TDD with API's like SPSite.Exists, SPSecurity.RunWithElevatedPrivileges, and others that do not lend themselves well to mocking and unit testing?
  • Joe, probably two parts to the answer, and excuse me I'm teaching you to suck eggs.

    First: Your not going to be writing unit tests for the SPSite.Exists method as you really have to make the call that Microsoft already did this.

    Second: You actually want to write some code, a method, that will in it's logic make a call to the SPSite.Exists method to determine the actions for that method. To make this a unit test you will need to mock out the call, which using TypeMock is actually pretty simple.

    Isolate.WhenCalled(() => SPSite.Exists(new Uri("http://www.21apps.com"))).WillReturn(true);

    Here I've just told Typmock to always return true when the SPSite.Exists is called within my method. You can extend this with checks on the parameters if you wanted as well.

    Regarding the SPSecurity.RunWithElevatedPrivileges this does present a challenge, but doing TDD should help as you really drive it from being testable. This often leads to you coding and testing the methods outside of the SPSecurity.RunWithElevatedPrivileges, i.e. less anonymous delegates, and also designing you classes so that any elevated calls are contained in very focused code wrapped in your own classes.
    This is probably an area that I should do some more blog posts on.
blog comments powered by Disqus