Test Driven Development with SharePoint

Test Driven SharePoint Development DEV371 Andrew Woodward

Andrew Woodward, MVP
Principal Consultant 21apps
Email [email_address]
Twitter @AndrewWoody
Blog www.andrewwoody.com/blog
Agile developer, recent white paper: Unit Testing SharePoint – Getting into the Object Model

Agenda
What is TDD
Demo: My First TDD
SharePoint adds challenges
Demo: My First TDD with SharePoint
Being Pragmatic

What is TDD?
T est D riven D evelopment
Or is it Design ?
Or BDD ?
Started life in XP
over 10 years ago!
Has evolved over time

10 Reasons TDD Sucks
I never have enough time to write the tests, once I’ve finished themain functionality
Testing isn’t my job, because it’s QA’s job to make sure I do quality work .
Unit tests don’t help me, because my code works perfectly the first time .
There’s no need to test drive my code, because the design handed to me by the architect covers every possibility
Running the tests is a pain, because it takes too long to scan throughall of the output to see if everything was fine
Running the tests takes too long, because loading SharePointand restarting IIS between tests takes forever
I can’t do TDD, because you can’t unit test SharePoint
I don’t like TDD, because I enjoy the hours I spend in mydebugger
TDD is just a fad, and it’s completely unnecessary anyhow since projects always succeeded before
(BONUS) TDD sucks because I agree with all of the points here, and I don’t understand sarcasm .
Quote From: Blue Sky on Mars Inspiration: Courtesy of AndersRask

So what is TDD?
As described by Uncle Bob in
‘ The Three Rules of TDD’*
* Robert C Martin, aka Uncle Bob

Rule 1
You are not allowed to write any production code unless it is to make a failing unit test pass.

Rule 2
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

Rule 3
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You may be thinking
This is stupid!
It will slow me down
This will stop me designing
This is &^@#%

Think about
Code is working every minute
Less debugging = less wasted time
How many test created
every hour, day, week, month, year
Confidence to fix up messy code
Documented API examples
Wouldn’t you love that for SharePoint

MY FIRST TDD
Create a simple magic 8 ball web part using TDD

My First TDD
Using 3 rules
Created Tests first to drive design
Refactored code and tests
No extra code we didn’t need

MY FIRST TDD WITH SHAREPOINT
Refactor the Magic 8 Ball web part to use SharePoint List

Custom 8 Ball Web Part
Testing influenced design
Designed from Public Interface
SharePoint dependency
Slow
Required Configuration
Introduced Isolator
Faked SharePoint objects
Focus on our logic

Best Practice – Why?
Improved quality
Less time debugging – lower cost
Cleaner code
Better design
Initially and continually
Documented by example
Automated tests
Write once – run many times

Best Practice – When?
You have commitment
Willing and able to invest time
You understand Why?

Best Practice - Being Pragmatic
TDD is hard to get started
Easy to learn the 3 rules
Initially slow and awkward
Mindset change takes time
Difficult to implement for Legacy code
Adoption takes time and investment
Experience is invaluable
However the rewards can be Profound

Predication!
2009 will be the year that SharePoint developers embrace Agile and TDD

Thank you for attending! Please be sure to fill out your session evaluation!

Thank you for attending!
Post conference DVD with all slide decks
Sponsored by

http://www.21apps.com	1363
http://www.slideshare.net	14
http://translate.googleusercontent.com	4
https://spsites.microsoft.com	1
http://203.208.37.132	1

Test Driven Development with SharePoint

by Andrew Woodward on Feb 09, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 1,383

Statistics

Test Driven Development with SharePoint — Presentation Transcript