Not quite sure why I\u00e2\u20ac\u2122m 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.<\/p>\n
What\u00e2\u20ac\u2122s SharePoint Retreat? Well it\u00e2\u20ac\u2122s a room full of geeks trying to improve the way they write code for the SharePoint platform. And it\u00e2\u20ac\u2122s 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.<\/p>\n
Yesterday\u00e2\u20ac\u2122s focus was TDD (Test Driven Development) and Unit Testing for SharePoint. Any of you who\u00e2\u20ac\u2122ve 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!)<\/p>\n
Back at the Best Practices conference in 2009, Andrew made a prediction \u00e2\u20ac\u01532009 will be the year that developers adopt Agile and TDD\u00e2\u20ac\u009d. 1 out of 2 isn\u00e2\u20ac\u2122t bad, I think nearly everyone understands the value of Agile, but TDD just hasn\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122re 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\u00e2\u20ac\u2122s the effort to learn how to do it, the cost of learning, but more importantly the cost of doing.<\/p>\n
I think the view I took mostly from yesterday is that if you\u00e2\u20ac\u2122re 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\u00e2\u20ac\u2122s are just right. If you don\u00e2\u20ac\u2122t do this, then you\u00e2\u20ac\u2122re going to spend more time thinking about how to do the tests, rather than what you want to achieve from the test itself.<\/p>\n
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\u00e2\u20ac\u2122d change something that would break an earlier test which had to be fixed, so it get\u00e2\u20ac\u2122s 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.<\/p>\n
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\u00e2\u20ac\u2122t broken the existing ones (This won\u00e2\u20ac\u2122t remove the need to test further though, so don\u00e2\u20ac\u2122t neglect the other test stages!)<\/p>\n
Now, as a SharePoint developer and consultant, I\u00e2\u20ac\u2122m going to put my hand up and say I don\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122m 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 \u00e2\u20ac\u02dcSoft\u00e2\u20ac\u2122 development i.e. xslt, branding etc. So I could probably use TDD on about 40% of my work at the moment.<\/p>\n
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\u00e2\u20ac\u2122s going to add an extra day to the cost. Certainly as the supplied I don\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122t use TDD, then it\u00e2\u20ac\u2122s likely I\u00e2\u20ac\u2122ll be overlooked.<\/p>\n
In this scenario, it\u00e2\u20ac\u2122s 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?<\/p>\n
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.<\/p>\n
| \n So, if my retrospective has piqued your interest rather than scared you (and I hope it\u00e2\u20ac\u2122s the former!) then take a look at Andrew\u00e2\u20ac\u2122s 21Apps site where he has some great white papers on beginning unit testing. http:\/\/www.21apps.com\/agile\/<\/a> There\u00e2\u20ac\u2122s also a book recommended by Andrew that is excellent for anyone interested in starting with TDD by a chap called Roy Osherove. <\/p>\n<\/td>\n |