SPRetreat TDD – a retrospective (See what I did there?)

Not quite sure why I’m up at 6 am on a Sunday morning writing a blog post, certainly the bed was warm and comfy, but my mind is still pretty buzzing from yesterdays SharePoint Retreat sponsored by 21Apps and Content and Code.

What’s SharePoint Retreat? Well it’s a room full of geeks trying to improve the way they write code for the SharePoint platform. And it’s fun too, we had a great time yesterday and learned a lot too. But before we talk about that, a quick thank you to Andrew Woodward and 21Apps for sponsoring food, beer and running the event and Wes Hackett of Content and Code for providing accommodation, and to TypeMock for providing a couple of prizes in the form of Licenses for their product.

Yesterday’s focus was TDD (Test Driven Development) and Unit Testing for SharePoint. Any of you who’ve been around the SharePoint community know that Andrew has been an advocate of both for a long time and him and Eric Schupps have often been quite vocal in their views on the subject at many a community event. (Not to say they oppose, just differ!)

Back at the Best Practices conference in 2009, Andrew made a prediction “2009 will be the year that developers adopt Agile and TDD”. 1 out of 2 isn’t bad, I think nearly everyone understands the value of Agile, but TDD just hasn’t taken off. I think the answer to why, is the cost. Not just in the cost of the licenses to do TDD, after all we’re in the software business and we understand that licensing is a necessary evil for what we do, after all we all want to be paid for our code. The other cost is the up front cost of TDD, there’s the effort to learn how to do it, the cost of learning, but more importantly the cost of doing.

I think the view I took mostly from yesterday is that if you’re going to use TDD, you need to do it a lot, The muscle memory used to develop the test needs to become as second nature to you as changing from 2nd to 3rd in a car when the rev’s are just right. If you don’t do this, then you’re going to spend more time thinking about how to do the tests, rather than what you want to achieve from the test itself.

So is the cost worth it? Well I think yes it can be. I found even in the short space of time yesterday that as we worked on code blocks and they started to grow, we’d change something that would break an earlier test which had to be fixed, so it get’s you thinking about how the process of development changes as you move along the timeline. Just how many hidden bugs are you introducing as your code grows that only come about when certain conditions are met. Is testing these conditions at integration or user testing the right time to find them? Most certainly not. Spending this time up front to develop these tests as you go, does add to the development time, but SAVES time at the latter stages of the project.

More importantly, if you (Or even someone else) has to return to the project code at a later date to add new functionality, You can see at a glance (or a quick ctrl alt T) that all the tests that exist are running fine, giving you more confidence in the code and improving readability. This means that you start on the actual work of adding the new features faster, and more importantly you can re-run those unit tests as you work, ensuring that your new features haven’t broken the existing ones (This won’t remove the need to test further though, so don’t neglect the other test stages!)

Now, as a SharePoint developer and consultant, I’m going to put my hand up and say I don’t use TDD and rarely if at all use unit tests, relying on manual testing and then integration and user testing at latter stages. The main reason, and possibly I’m deluding myself here is that I tend to work on small projects, maybe a few web parts, some event handlers, a page or two and also a lot of ‘Soft’ development i.e. xslt, branding etc. So I could probably use TDD on about 40% of my work at the moment.

My main question would be, how do I sell the value of using TDD on a small perhaps 2 day project for a client if it’s going to add an extra day to the cost. Certainly as the supplied I don’t want to foot the bill for that extra day, I want to pass the cost on to the client and recoup my efforts. but if I go in quoting 50% more time than my competitor who doesn’t use TDD, then it’s likely I’ll be overlooked.

In this scenario, it’s hard to sell the value of TDD and Unit Testing to the client. What is the likelihood that you or anyone else is going to revisit that webpart code? How long is the testing actually going to take doing it manually? BUT and this is quite a big but, IF I was to put the effort in now and absorb the cost of adding TDD to my projects now, would I recoup that cost in the future because of the improvement in my speed of production and testing and my muscle memory improves?

I think we sometimes shy away from things that we see as a lot of effort for little return and on the face of it, TDD is possibly one of those things, but I think once you scratch the surface, the value and potential starts to show you may begin to reconsider whether the effort may in fact be worth it in the end.

I’m now going to go away, make a cup of tea, then sit and redo all of the exercises from yesterday and just see how much the old muscle memory kept. once that’s done, I’ll post it here.

Edit: Because of the length of time it’s taken to do the TDD and get the screenshots, I’ve broken the post up into a series.. Part 1 and the index is here.

 Part 1 — SharePoint Retreat–TDD and Unit Testing, the methodology used

Regards

Paul.