Online. Offline. Bottom Line.™
(skip to the content)
Home | About | Jobs | Privacy Policy | Contact | Login or Register
There is one word that is guaranteed to generate excitement in mobile development communities right now - Android. Google’s venture into the mobile SDK realm was eagerly anticipated, and its release, paired with a development challenge, didn’t disappoint. Now however, as the freshness wears off and serious development begins to become more commonplace, Android’s first real shortcoming becomes clear. Unit Testing…
There seems to be no hiding this story today. The short of it…Google is experiencing some delays with its roll out of Android and the first devices that will support it. Google had stated earlier this year that the first Android phone would ship in the second half of 2008. Today’s report from the Wall Street Journal reported a slow down which quickly down spiraled to reports of delay and “A Blow to Google’s Mobile Ambitions”. The apparent frenzy around the story appears to be short lived as more blogs are now clarifying the state of Android and restating that late Q4 still falls within the second half of 2008 where Google predicted devices would first emerge. As far as Google is concerned ”We remain on schedule to deliver the first Android-based handset in the second half of 2008 and we’re very excited to see the momentum continuing to build behind the Android platform among carriers, handset manufacturers, developers and consumers.”
I recently received an email from a colleague about a particular issue they encountered, and I couldn’t help but share. This engineer was working on the second version of a project that had been released about two years prior. The original author of the code apparently did not subscribe to the idea of unit tests, because there was no test suite at all. Now, two years after the initial release, my colleague is adding tests and discovering that some features simply never worked to begin with…
As many people know, the most current Java Release Family is Java 6.6. It was made available to the general public back in December 2006. Java 7 - Codename Dolphin is in beta, but the development community is expecting it to be released sometime in 2008. With the introduction of the new, it is also time to say goodbye to the old. The Java 1.4 family will reach its End of Service Life (EOSL) this year, in October 2008. This means that that release family will no longer be supported by Sun, nor will they distribute the SDK or JRE anymore. Similarly, Sun announced in April that the EOSL for Java 5.x will be in October of 2009.
What does this mean for companies still developing against Java 1.4 or Java 5.0?
When new engineers are being brought into the fold of unit testing, one question invariably arises: “Should we test getters and setters?” The answer, in the humble opinion of this engineer, is yes. This is by no means a new argument; it has been raging across the software development field for years. Let’s face it, public getter and setter methods are (normally) inherently simple, and writing unit tests for them seem to be a waste of time – testing the language’s ability to set and pass variables instead of any actual code. But there are a few dangers lurking in not testing them…
Whenever I advocate testing getters and setters, the first argument I almost always get is, “A simple getter and setter can’t break.” Wrong. They can break, and I have seen it happen.