The Cafes » Testing

There are many reasons to write your tests first. An oft unmentioned benefit is that it makes the programmer stop and think about what they’re doing. More often than you’d expect, the obvious fix is not the right answer; and writing the test first can reveal that.

For example, recently Wolfgang Hoschek pointed out that in XOM the Attribute class’s setType() method was failing to check for null. Once he pointed it out, it was an obvious problem so I opened up Eclipse and got ready to fix it:
(more…)

While it may be a slightly too extreme position to say that tests are the only spec, I think it is absolutely reasonable to consider tests to be a major part of the spec. Indeed a specification without normative test cases is far less likely to be implemented correctly and interoperably than one with a solid normative test suite. The more exhaustive the test suite is, the easier it is to write a conforming correct implementation.

Cedric Beust presents the question, “how do you specify an exponentiation function with a test?” as a counterexample to tests as specs. Actually I don’t think it’s all that hard. Here’s one example:
(more…)

The final chapter of the recently published Java I/O, 2nd edition focuses on the Java Bluetooth API. Like about half of what’s going on in Java today the Java Bluetooth API was defined and developed in the Java Community Process (JCP). I spend a lot of energy criticizing the W3C process, but compared to the JCP, it’s a model of sanity.
(more…)

Here’s an interesting article that is totally, completely 180 degrees wrong. I’ve said this before, and I’ve said it again, but I’ll say it one more time: final should be the default. Java’s mistake was not that it allowed classes to be final. It was making final a keyword you had to explicitly request rather than making finality the default and adding a subclassable keyword to change the default for those few classes that genuinely need to be nonfinal. The lack of finality has created a huge, brittle, dangerously breakable infrastructure in the world of Java class libraries.

(more…)

There’s one trap I fall into repeatedly while doing software development of any kind: testing, debugging, coding, documenting, anything. And it happens in every language I’ve ever worked in: Java, C++, Perl, CSS, HTML, XML, etc. The only difference is how much time I waste tracking down the bug.

I have this on my mind now because I just lost at least half an hour to this while working on the CSS stylesheet for this very web site. I have had many students show up during my office hours for help with debugging this problem. I have had at least one company pay me lots of money to fix this problem for them (though they didn’t know this was their bug or they wouldn’t have needed to call me in the first place). I can virtually guarantee you’ve made this mistake too. What is the mistake?

Editing the Wrong File
(more…)