Mar 27
I seemed to always have a problem with the unread bit getting "forgotten" on Mail.app. I thought it was a bug on Apple's product but apparently the bug is actually on the GPGMail bundle. Here is how to fix it.
Mar 23
These are pretty funny..
Novell releases Get a Mac spoofs
The first video plays off the Win/Mac rivalry and pokes fun at how the industry often ignores Linux and its surprising (to some) user base size. The second video is arguably funnier, as it does a great job of poking fun at the way MS and Apple market their products while pointing out open source software's advantage of being a community effort. [digg - tech news / apple / dig]
Mar 21
Who would have known? I've been using TextMate for a while now, and now I find out that you can use it to post blogs. I guess you learn something new every day. here's the movie on how to use it.
Mar 09
Best Practices, Methodology No Comments
This is awesome..
Development: "You want answers?"
Marketing: "I think we are entitled to them!"
Development: "You want answers?!"
Marketing: "I want the truth!"
Development: "You can't handle the truth!!!Son, we live in a world that requires software. And that software must be built by people with elite skills. Who's going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don’t think so.
Agile Chronicles: A Few Good Managers
technorati tags:agile, funny, development
Mar 06
Best Practices, Java 2 Comments
Every assertion should be thought from the standpoint of
Translation: assertTrue should always, always have a message.
Consider the following:
assertTrue(mv.getViewName() .startsWith(myController.getSuccessView()));
This will only return "assertion failed". Which is great, but how do we know what happened? If this is buried on one of the lunt automated remote builds, how am I supposed to know what is going wrong? Which is the expected? What actually happened?
A much better version of the same looks like this:
assertTrue( "Was expecting something like " + myController.getSuccessView() + " but was " + mv.getViewName(), mv.getViewName() .startsWith(myController.getSuccessView()));
Same assertion, but now it tells me more specifically what's going on and I can fix bugs with it. Once I set this on the test, it becomes easy to see what was going on.
I recently had a Saturday with some other Bay Area developers where we did a lot of thinking about testing, so expect some more advice in the future as I collect my notes.
Remember the goal of unit tests is to "find bugs" (thanks Harry!). An assertion without an associated message merely notifies you that a bug occurred but doesn't actually "find it". As you are writing your unit tests, make sure you find it as well.
technorati tags:testing, junit, assertions, java
RSS