The Twitpocalypse and Unit Testing
June 13th, 2009
If ever there was a clear example of the need for unit testing during builds, it’s the integer overflow problem on Twitter – aka, the Twitpocalypse.
For those not in the know, Twitter uses an incrementing integer as an identifier for each message on the site. On June 12, 2009, a message crossed the maximum integer value that could be stored in a 32-bit signed integer (2,147,483,647).
All messages created after that moment had integer values that would overflow the space allocated to the id.
This wasn’t a problem on Twitter.com. They’re surely on some rockin’ 64-bit systems and are continuing along as always.
The problem is with third-party applications using their API. When an application requests a list of status messages from Twitter, it receives the data in a format like XML or JSON. All values are stored as strings in those formats.
When the response is parsed, the string representing the status message id will be converted to a number. Applications that still use signed 32-bit integers will not be able to properly convert the string to an integer and will probably crash.
This problem is hitting a few Cocoa Touch applications. Tweetie seems immune, but the current release of Twitterrific and the in-beta Birdfeed both suffer. This is through no fault of either Craig Hockenberry or Buzz Andersen, though.
Buzz’s app, Birdfeed, is still in beta. Those of us testing it understand that beta means beta. He’s cracking on a fix now.
Craig preemptively fixed his issue well in advance, but – as I understand it – Apple is sitting on it instead of pushing it into the App Store.
This is just one of many ways Apple continues to please developers endlessly with their transparent, fair, open distribution channel.
Lots of folks want to blame Twitter, or shift some of the blame to them.
This is not a Twitter problem. They adapted their system and encouraged developers who use the Twitter API to remain in parity.
It’s probably true that Twitter could have made a bigger deal of the issue, but I think they did a solid job of keeping people informed.
Most people had ample time to update their code, and many of them did.
Daniel Jalkut suggested that Twitter might have provided an endpoint for the API that simulated large integer values, so application developers could test against the newer ids. I heard similar statements by folks attending WWDC.
I think this exposes a slightly dirty secret in the Cocoa world: most Cocoa and Cocoa Touch devs avoid automated testing. Unit tests are few and far between. From what I hear, Apple doesn’t even enforce units.
When you see regression bugs in Cocoa apps, you can assume the issue is in a lacking test suite.
The Cocoa community should learn two things from the Twitocalypse:
1. Write your units.
2. Submit to the App Store at least time * infinity in advance.
I’m about 50% on having test suites in my (admittedly, unreleased) iPhone apps. The half that have tests have strong coverage, though. Those that don’t are from the early SDK days, when the only way to test was with the Google Toolkit.
