Going TDD

As the new guy on the Ohloh development team, I’ve been immersing myself in the details of Ohloh’s implementation. Do you face similar challenges to the ones we face at Ohloh?  We have a body of code that has been in development for some 7 years, with all the technical debt that implies.  Well over a billion records in a database, over 86,000 lines of code, thousands of active and dedicated users.  And we have a long list of features that we’d like to implement.  Oh, and a few bugs – imagine that!  Ohloh’s crawlers continuously work their way through nearly 560,000 projects in hundreds of thousands of repositories across well-known forges and foundation sites, vertical hosting sites, and single-project sites supporting the most widely adopted SCM systems, with remarkably few failures considering the diversity of the FOSS world.  Serious kudos to the team who built this!

Now, to not diminish their efforts and contributions in the least, we observe a lovely quotation from Edsger Dijkstra:

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

7 years of code writing, growing functionality, changed ownership and business priorities, and we have the completely unsurprising and standard mix of “wow, that’s brilliant” sometimes right next to “what the heck?” code.  Oh, and a dearth of test coverage. That sets the stage for where we’re going.  In previous positions I’ve had the opportunity to learn to use test-driven development. The Ohloh team has been messing around with this methodology for awhile but more the facade and intent, rather than the complete, disciplined adoption of this technique.  So, to spread the wealth, diminish our pain and pursue the gain of TDD, we’ve assembled some internal notes, guidelines and policies, and we’re aligning our coding styles and conventions, design patterns, refactoring choices and test development across our geographically spread-out team, to help us accelerate our progress and keep on bringing you the new features and analyses you want from Ohloh.

Which brings me to the real point of all this.  Gary Bernhardt of Destroy All Software has some inspirational videos, including one on building a test suite that does a great job of illustrating the process.  Many thanks to Gary for producing this series and his blog, extracheese, and for sharing his wealth of expertise with the team.  And, guess what? Gary was one of the direct contributors to the Ohloh code back in its early days before Black Duck acquired the site.  That’s serendipity!

About Peter Degen-Portnoy

Mars-One Round 3 Candidate. Engineer on the Open Hub development team at Black Duck Software. Family man, athlete, inventor
  • ZeroOne3010

    The next logical, big step for Ohloh would be if the service started tracking test-related metrics of all the FOSS projects! The most trivial one would be the ratio of code to tests. This’d have to be tracked per programming language, as I’m sure some languages have less verbose testing frameworks than others.

    • Peter Degen-Portnoy

      Thanks for your comments. We are talking about this and similar features as part of adding quality focused analysis on Ohloh. Ratio of code to tests, cyclomatic complexity, tagging of code trees (logic, test, configuration, third party tools, etc.) are all part of the active conversations.

      • Sounds great! I only suggested the ratio of code to tests because that’d be fairly trivial to implement. Trying to track, for example, code coverage would be way more difficult as that would require you to actually run the tests.