I know this post will be heretical to some in the software development community, but that's why it's important to write about it.  In short: I don't do any automated testing of the StatSheet Network sites, but rely on GoogleBot to notify me of bugs.

A little background before I continue...I incorporated StatSheet in June 2007.  The company has been a single person entity since (and bootstrapped).  I've done all the programming and design with the exception of logos which I've outsourced using services like 99designs.  A recent count shows the StatSheet codebase is well over 200,000 lines of code for all backend and frontend code.  That's translated to over 1.5 million unique URLs I'm submitting to Google via sitemaps that cover statsheet.com.  

Early on I had to figure out how I was going to test this beast of a site I was creating.  Currently StatSheet covers College Basketball, NBA (partially), College Football (partially), and NASCAR.  I have historical data for many seasons.  That means lots of players, teams, coaches, conferences, etc.  Lots of permutations of what stats are available with those players, teams, conferences, etc.  I track thousands of stats and attributes across those sports.  It is statsheet.com's job to make that information available in easy to digest ways.

Instead of writing a bunch of test code to go through all the various permutations that could result in errors on the front-end, I found GoogleBot (Google's web crawler) was doing a pretty good job of scanning the whole site in a timely manner.  I set up code on the front-end to email me anytime there is a Server Error.  I found early on that when I'd push out new changes, GoogleBot would find obscure bugs with infrequently visited pages much quicker than I (or even my users) could.

So I abandoned any formal attempts to automate testing of StatSheet.com (at least for now).  GoogleBot is constantly scanning the site and notifies me when it finds bugs (via the email on Server Error).  That means I can keep moving full speed ahead writing new code, trying to add more features and visualizations of the data without spending a lot of time writing test code.  I've found this works well in the lean, single-person company mode I'm currently in.  You can avoid much of the formality of software engineering if you are the only person that ever touches the code.

What about when developer #2 joins StatSheet?  That will be a great!  But it also means I'll need to introduce more formality.  We'll likely need to introduce some automated testing at that point.  And yes, it will be a bit of a pain to go back through and write tests.  But unless I can get StatSheet to the point where I'm bringing in enough revenue (or if I decide to raise outside funding) it doesn't make a difference how much test code I've written.  In these early days of the company, the important thing is getting the site as functional as possible and worry about testing later when it becomes more important.

Posted by Robbie | Permalink | Comments

About StatSheet.com

Have a suggestion?
Let me know