SharePoint and TDD

Posted on 7/1/2009 @ 6:21 PM in #Vanilla .NET by | Feedback | 4799 views

A quick point of mention: The general community that pushes TDD/Agile/Scrum can, in my experience only, be a bit pushy. Constructive comments are welcome, but any personal attacks, or vulgar comments will be mercilessly deleted.

<Added Later>

Eric Shupps and Andrew Woodward both wrote a long blogposts in response to this. Eric and Andrew are both extremely smart guys, and I hold them in high regard.

I tried leaving a comment on Eric's blog, but it didn't go through .. so I am writing it here instead.

Eric says -- "As usual, Sahil is nothing if not incendiary, but his basic premise is that the actual amount of code written for the average SharePoint project doesn't warrant the overhead of a structured development process (he just happened to choose TDD in this instance)"

I am being misquoted here. A structured development process is MORE necessary in SP projects than .NET projects, because things such as TDD are HARDER to apply. I never said that you should use bad dev methodologies with SP projects, only that the ROI of TDD specifically on SP projects is lower than .NET projects.

</Added Later>

Okay so here we go! I was at NDC last week, and there were a lot of very intelligent people there in the speakers room or otherwise. As I was walking around on the floor (which frankly I prefer to do than sitting in the speakers room – where everyone is a speaker and hardly anyone is a listener). While on the floor, multiple people asked me a very straightforward question - “What do you think of TDD in SharePoint?”

Well, I think it isn’t worth the effort.

There is nothing wrong with TDD, and in many projects it is quite beneficial. But I completely disagree with the viewpoint that it is the only way of doing things, and every other way is wrong.

Lets take a step back and consider TDD and it’s brothers and sisters. Lets look at everything in perspective, Agile, Scrum, and everything in between. People have used the waterfall methodology for a very long time, and many have expressed their frustrations with it. The basic premise/issue of waterfall is that you need to catch your changes early in a project, because as you discover changes in a project in later stages of a project, the cost of change to implement such a change is much higher. But we know that in the real world, change occurs. So all these methodologies, focus on reducing the cost of change.

So, in order to reduce this cost of change, there is an upfront and ongoing cost, of implementing procedures and practices that help you reduce the cost of change – remember, nothing is free!? So there is a cost, to reduce the cost of change. And thus, if the cost of change is greater than the cost/investment required to reduce the cost of change, then it makes sense to use it for your projects … otherwise it doesn’t!

So it all boils down to, what are the characteristics of a project that help you identify, in which projects, the investment/cost to reduce the cost of change, is lesser than the cost of change itself!

The answer is larger, complex projects with tonnes and tonnes of code!

So, now lets take a typical SharePoint project. Of course there is a range and gamut of SharePoint projects, but lets pick the average summation of them all. A usual SharePoint project involves many things,

  • Customer communication and prototyping – usually much much more than a typical .NET custom dev project.
  • Plenty of attention to the IT Pro side, where you decide logical and physical layouts of your servers, networks, and your site collections. Custom dev .NET projects are usually simpler to setup and plan.
  • A significant effort in branding – usually greater than your typical .NET project, simply because the master pages and CSS and JS of SharePoint are much more complex.
  • Focus on scalability, when balancing between requirements, and best practices, and experience!
  • Writing some code
  • Establishing roles within your team, which is different from the nature of the SharePoint project. Usually this is more involved in an SP project than a custom .NET dev project, simply because there is a higher overlap between ITPro and Dev in the case of SP.
  • Training required – your business users will need training on the project ~ again, usually more significant than a simple .NET custom dev project.
  • Architecture, and functionality bargaining per RUP for COTS – where there are many ways of achieving a goal, and the way picked is a delicate balance between budget, demands, and technology.

Thus in a typical SharePoint project, the portion where TDD is actually applicable is very small – which is the writing code part. In most, not all, SharePoint projects, we write code as small bandaids across the system, to cover that last mile – we don’t write code to build the entire platform, in fact the emphasis is to write as little code as possible, while meeting the requirements.

So already, the applicability of TDD as a total percentage of the project is much smaller.

Now, lets look at the code we write for SharePoint. These small bandaids that can be independent of each other, are comprised of some C#/VB.NET code, but a large portion of the code is XML files. These large portion of XML files, especially the most complex parts, define the UI – something TDD is not good at testing anyway. Yes I know attempts have been made, but attempt != standard. And the parts that are even pure C#, we deal with an API which does not lend itself well to TDD. You can TDD SharePoint code, but it’s just much harder.

So you have to ask yourself, that this 5% of the actual project effort, where you WILL indeed write code, which is possible, but is difficult to make test driven, in that 5% is the cost of reducing change, worth dealing with the actual cost of change?

In a rare borderline scenario, I bet the answer will be yes! But in most scenarios, the answer is usually no.

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

Sound off but keep it civil:

Older comments..


On 6/21/2009 7:58:19 PM Herve said ..
Great analysis. I totally agree.


On 6/21/2009 11:25:40 PM Ruwan Fernando said ..
Sahil,


Nice post and I fully agree that the SP API doesn't lend itself well to TDD. I've on several occasions started out to develop mini-frameworks for the SP development that we do and most times due to budget or time constraints had to shelve this effort for later. I'm sure I'm not alone in these efforts and have seen several other SP DALs etc out there which seem to indicate that I've been taking baby steps along a path that others have gone before. To me this indicates that as the SP platform is better understood and tool support improves (e.g. VSeWSS 1.3, VS 2010 and the already existing non-MS tools) there will be more custom code written versus the band-aid code that is currently prevalent.

Also, given that most code that makes it into production tends to stay there significantly longer than the developer anticipated, I see a reason to encourage automated UT if not full blown TDD. Anyway, that's just my thought on the topic.

-Ruwan


On 6/22/2009 5:38:24 AM Mikael Svenson said ..
I think you grasped the essence quite well.

If all you're doing is Sharepoint UI, then it might not be worth it, but if you're using SharePoint as an application host and developing a lot of code modules (which in theory could be hosted anywhere), then there is a benefit.

And it's the developers responsibility to analyze the project at hand, and choose the right methodology and tools.


On 6/23/2009 12:15:03 PM Andrew Woodward said ..
Sahil, I had to comment on this one - but time is against me so this will be brief.

You are correct in your break down of most SharePoint projects, the actual amount of code you develop can be relatively small, but as Mikael says SharePoint as an Enterprise Application platform is growing and the code written for these applications is increasing (just becuase it does not touch the SP object model does not make it code). However you have missed the point about TDD and SharePoint.

You used to be a C# MVP right? Do you agree that in order to develop good quality solutions (and I mean enterprise class not in the shed hacks) you need good processes, you need to implement code reviews, unit testing, integration testing, performance testing, scalability testing, security testing etc etc.

In this development of an enterprise application you may, based on experience, choose to use techniques like TDD in order to help you define a good api, and testable code. You may not use TDD but you will want to do Unit Testing where possible and where it addes value to your process.

The problem is the question is wrong, what people are really asking is should we be adopting good development practices to the code we create for SharePoint project. Hell Yes of course you should. If your team is good enough then some of that code may be developed using TDD, but TDD is not the question or the answer - it is just a technique that people like to use to help them create testable code.

What I really like is that people are starting to ask the question, even if you got didn't understand the real question.

Andrew


On 6/23/2009 1:13:31 PM Sahil Malik said ..
Andrew - thanks for your comments.

I think you are right, the question really is "Should SP projects use good practices?". ABSOLUTELY YES! They should.

I think my point here was specifically about TDD. TDD IMO and only MY O, is not so applicable to SP. However, things such as proper requirements/frequent customer feedback/unit testing/all those good dev. practices apply!

S


On 6/23/2009 3:19:36 PM Andrew Woodward said ..
I don't understand why you have such a dismissive view on what is really just a technique that a developer will use to create testable code.

You agree Unit Testing, right?

So you agree you need to write testable code? therefore if the developer is confident with doing TDD why would they not use this technique in creating testable code? The resultant code produced and unit tests are likely to be the same (assuming you have good developers).

If your trying to counter the view that ALL code should ONLY be developed using TDD then that I agree with you, but there I cannot see any rational for saying TDD is not applicable to SP. It's just stupid.

Andrew


On 6/23/2009 10:36:06 PM Fred Morrison said ..
I would love to do TDD with SharePoint workflows (MOSS 2007, not WSS), but the lack of a good mocking capability seems to be the biggest hindrance. In fact, I'm kind of jealous of people who can start by writing the test, create the objects, etc.

However, how am I supposed to run TDD on XOML or worse, custom C# activity code in a MOSS workflow originally (and still dependent on) Visual Studio 2005 and four different milestone dates that affect the eleven possible directions the workflow can take?

Thanks to new features in VS 2008 SP1, I can experiment with small nuggets of functionality in what I call a proof-of-concept workflow and then use that experience to enhance or change the big workflow that still needs VS 2005. But that's still not what I would call true TDD for custom MOSS workflows.

The best I have been able to do is come up with a way to "compress time" that allows me to rapidly test all eleven possible scenarios of my most complex custom workflow in a matter of hours instead of weeks.

Maybe this situation will improve in SharePoint 2010? Experience teaches me to hope so, but not expect much.


On 7/1/2009 6:25:04 PM Sahil Malik said ..
Fred exactly. Well you COULD TDD WFs, but again thats the whole point I am trying to say here - even in a very code-centric thing such as WFs, TDD is hard to apply. Let alone other aspects.

And I am not a very big fan of Workflow Foundation in General.


On 7/1/2009 6:41:16 PM E. Shupps said ..
Your comment is up; I have approvals turned on to limit spam. What I took from your post, even now that I've read it again, is that you're against unit testing in general in a SharePoint context. I certainly agree the the TDD crowd is overly zealous (heck, that was a main point of my original SPTDD post) but I think we diverge on the issue of how much code is involved in a typical project and the core value of unit testing in these instances. As I stated, it's all a matter of perspective. If we agree that Unit Testing is good and TDD isn't so good then we're on the same page!


On 7/1/2009 6:44:55 PM Sahil Malik said ..
Thanks Eric :).


Yep TDD crowd is over-zealous.

About "How much code", well okay we respectfully diverge there. While I can't seem to avoid writing code in SP projects (OOTB only does so much), still the overall quantity of code is lesser in SP projects than .NET projects ~ atleast in the projects I've worked on.

Unit Testing is essential! Just as many other good dev techniques are.

As always, thank you for your perspective.

S


On 7/8/2009 1:39:20 PM Reba said ..
Since there is a marked consensus here on the SharePoint/TDD bundle, I would like to divert the discussion to a slightly different point (based on one of the post's initial premises, btw), if I may: how about Agile/Scrum to go with SharePoint? It seems like equally not worth it for smaller and less demanding projects if you will, but for the magnitude type, couldn't this be something to consider?


On 7/8/2009 11:51:40 PM Sahil Malik said ..
Reba,

I think Agile/Scrum is the only way I'd ever handle a complex SP project.

S


On 4/14/2010 2:19:31 AM Pedro G. Dias said ..
In my view, TDD is simply a name for a specific sequence of development. I agree completely that the programming model for SP is overwhelmingly complex (esp. for someone like me who's never seen the beast until I joined Sahil's course on it), but that wont change the way I produce code.

I rarely write a single line of production code before I have defined what I want it to do first in one or more unit tests - because it's not testing, it's ensuring behavior, and that is what TDD is all about.

The sad thing, of course, is that Continuous Integration, Nightly builds make less sense with SharePoint, but those are just some of the toools available to a TDD oriented developer, not all of them.

The fact that there is less code does not warrant that I give that code less attention to detail, so I disagree with Sahil on that you can change paradigm when you have smaller things to write.

High standards - always! :)