Bob Martin now wears a small green rubber band. His explanation:
I wear a green band on that I put on about six months ago. This band is a statement of professional ethics. The band signifies that I unit test my code and I know it works.
— Bob Martin SD West 2006
Bob went on to explain that testing 50% of your code isn’t enough that the target should be 100% or at least the high 90s. Do you really want to explain to your customer that you only know that half your code works.
I like the little green band idea, as an obvious visual. I’m not sure it will catch on in the general TDD world, but I like that Bob’s still focusing his considerable presenting skills on convincing developers to test.
Just downloaded and installed the newest version of NetNewsWire 2.1 Beta. In the first 5 seconds it solved one of my most annoying problems with prior versions. When you click on a link for more… NetNewsWire opens a new tab which is really a session of Safari.
Since I rarely go through and close all these windows they tend to build up often I’ll have 50 to 100 tabs opening. In prior versions when things got slow I’d chose
Window > Close All Tabs
. That worked fine, but it would launch the dreaded spinning beach ball and take at least 2-3 minutes to finish. Annoying, but I eventually got used to it.
I just closed 68+ windows in 2 seconds. Very nice. (And I still haven’t tried out the real power feature, syncing online through NewsGator.)
“If you like this presentation, feel free to buy one of my books, they have them up at the bookstore. Or you can just give me five dollars, I’ll make more money that way.”
— Luke Hohmann (SD West 2006)
So in case you didn’t already know, writing a technical book isn’t a venture you undertake for profit. I have heard that the average technical book has a press run of about 3000 and that authors end up seeing very little after all the costs are taken into account. Does make you appreciate the effort people will undertake to share knowledge.
I attended a talk today at SD West 2006 really hoping to hear some hard earned lessons on better approaches to JSF development. Heck, the talk was entitled:
JavaServer Faces Programming and Best Practices
Unfortunately I got a high level overview of JSF and how great it
is will be with JSF 1.2. The whole spiel about the 6 phase event life-cycle and how great it is that you have another XML configuration file and another tag library. It turns out the best practices are part of Sun’s blueprints.
The JSF blueprint stuff is almost laughable. They actually use this statement on how to do templating in JSF:
As we saw, a developer can simply create a layout with
then copy and paste the same template to each page. This is a quick and easy way to develop web pages.
Great example of code reuse that cut and paste pattern. Isn’t that in the Gang of 4 Book as a classic pattern?
From what we heard the solution to most of our problems with JSF was to use Java Creator Studio 2. We got a quick demo of it. Nice clickity, click interface, you drag and drop a GUI widget and then link it directly to a database table, and you’ve got Enterprise Architecture.
As it turns out the most valuable part of the talk was gathering anecdotal evidence. Despite this being the only talk about JSF at the whole conference with 280+ sessions there were only about 30 people there. When she asked how many of us were using JSF only about 10 of us raised our hands. When she asked if people were using Struts virtually the entire room raised their hands.
The JSF story is still frustratingly incomplete.
At SD West 2006 today I attended a talk by Cedric Beust on TestNG entitled:
Beyond JUnit: Introducing TestNG, Testing the Next Generation
In 90 minutes he made a compelling argument for TestNG. It obviously has more features than JUnit and you can use the annotation features even if you’re stuck on Java 1.4 since they implemented it with Javadoc comments. I was able to install the IntelliJ IDEA plugin and get it up and running in about 10 minutes so I could play around with it. Some of the features you can do with the annotations include:
- No need to extend any class.
- Don’t have to start methods with <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
- You can group tests using annotations like “functional”, or “integration” or “broken”.
- You can allow parameters to be passed into tests.
- You can stop running tests without commenting them out, say stick them in a broken group.
- You can test threads.
- You can set a <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
so that a test that might be dependent on a flaky resource won’t just fail.</li>
- You can specify the order tests execute in.
- You can specify to use a skip option so dependent tests won’t be run if an earlier test fails.
- A distributed option for running on multiple machines has been developed and should be added soon.</ul>
It all sounds great. Why wouldn’t you switch?
Well Cedric talked about the primary reason I don’t find it compelling to switch or at least not right now. Someone asked him why he hadn’t just asked Beck and Gamma about enhancing JUnit. They said fine until he told them he wanted to add an option to specify the order of the tests. At that point they said on philosophical grounds that they weren’t going to do that, non-negotiable.
The point is JUnit is a unit testing framework that focuses on true unit tests. The idea that tests can be run in any order is a powerful supporting feature that helps force developers to write tests that test only individual small units of code. Many people still write unit tests that are more functional tests and cross multiple layers of an application or require a lot of setup merely to run. I have to agree that I fall in with Beck and Gamma here.
My approach for now is to rely on JUnit for all developer unit testing, and do the integration/functional/acceptence tests in Fitnesse. One of my biggest worries is that developers start taking advantage of say labeling a few tests as “broken” in annotations and then not running those unit tests. The point is when a test gets broken it needs to be high priority to fix it or delete it if it’s no longer relevant. Labeling tests broken and just moving on supports negative practices. If we were further down the TDD path, I might be less worried about missteps, but that’s the future.
Still, TestNG has a compelling set of features and especially nice use of annotations. If one of my developers wants to try it out for a future project, I’ll be completely supportive. It’s always a lot easier to evaluate the difference when you actually use the tool on real world code.