laying the agile groundwork at digg

user warning: Table './johnandcailincmsdb/node_counter' is marked as crashed and should be repaired query: SELECT totalcount, daycount, timestamp FROM node_counter WHERE nid = 835 in /var/www/drupal/includes/database.mysql.inc on line 172.

i'm currently working on re-engineering many of the development processes at digg. we're adopting a number of practices from the agile world that complement the type of development that we do. these practices include: build automation, automated deployment, daily scrums, short releasable time-boxed iterations, simple design, refactoring, and just-in-time specification.

we've decided to be agile about our adoption of our new agile processes, introducing them incrementally, measuring the results along the way and iterating as necessary.

as we worked through the cascading dependencies of our adoption path, it quickly became clear that automated testing had to be a cornerstone practice if we were going to make a success of the others.

our lifecycle

we've been reviewing our development life-cycle, pondering how we should best introduce automated testing into it. specifically, we're looking at:

  • specification: changing our specification process to define new functionality as atomic features. these features are just-in-time specified as a set of acceptance tests. a large number of these tests will be automated during development.
  • development: changing our development processes to be test-driven, that is, writing unit tests for all our functionality before we write the code and writing acceptance tests as we go along.
  • integration: checking in all code multiple times a day and continually/automatically running our unit tests and acceptance tests on each project branch.
  • environment and promotion: automatically generating and configuring virtualized test-environments and automatically promoting the latest test builds to them
  • data management: automatically generating realistic data-sets from production data for use in testing and integration environments and supplementing this with mock-objects

testing technologies

we're adopting several different open-source technologies to implement our automated testing solutions, including:
  • PHPUnit: php's member of the xUnit testing framework family
  • phpUnderControl: a php add-on to CruiseControl that integrates several capabilities into a continuous-integration environment with metrics and graphical visualizations. capabilities include testing, software metrics, documentation and coding standard enforcement.
  • Selenium: a portable testing framework that allows recording user interface tests and running them directly in a number of web browsers.
  • Twist: a platform for simple definition and management of acceptance tests.
  • SVN: for source-code-control, Trac for wiki and issue tracking and the Agilo Trac plugins for agile project management tools.

getting help

automated testing is a large and complex subject. we've been lucky enough to have had help from some of the brightest minds in the space.

recently sebastian bergmann spent a week at digg's offices. sebastian helped to kick-start our system setup and spent some time educating us on best-practices for php-based unit testing.

we also had the pleasure of a 3 day visit from håkan råberg from the twist team at thoughtworks. håkan helped setup and better understand the capabilities of the twist platform for defining, structuring and managing our automated acceptance tests.

marching on

we still have a long way to go. i'll keep you updated on how our process develops and how our technology choices work out for us.

Hi John, Came across your

Hi John,

Came across your blog via google. I would love to get an update on the transformation of digg into an agile process.

Specifically: Was there any developer push back? What were the pains about switching over to test-driven development? Did development time lengthen because of the test-driven dev? Has the quality of code improved because of the change?

Also, what was the biggest driving force? How did you convince the developers to do this? Was this an easy thing to do?

Sorry for all the questions. I've been managing a team of developers at an agency and just wanted to see what the pitfalls were before switching over to test-driven dev.

Thanks for all the posts you've written and the time for reading this comment!

-d

Hey David, Good to hear from

Hey David,

Good to hear from you. If you'd like to contact me directly, I'd be happy to talk through the issues etc.

Cheers,

John.

post new comment

the content of this field is kept private and will not be shown publicly.
  • web page addresses and e-mail addresses turn into links automatically.
  • allowed html tags: <h2> <h3> <h4> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • lines and paragraphs break automatically.
  • you may post code using <code>...</code> (generic) or <?php ... ?> (highlighted php) tags.

more information about formatting options

captcha
are you human? we hope so.
copy the characters (respecting upper/lower case) from the image.