Interesting Bits

Javalobby review of JUnit Recipes

I was just alerted to a new review of JUnit Recipes at javalobby.org. The review is quite positive, and that always makes me smile. I was dedicated to the idea of not writing Yet Another TDD Book, something that the reviewer complimented:

I was initially caught off guard with this book, as I had expected a text heavily saturated in Test Driven Design philosophies. [...] Recipes stands out from other JUnit books in that is not written from a Test Driven Design (TDD) perspective. While the authors are advocates of TDD they defer many of its philosophies to other books, leaving Recipes clean of best practice Bible bashing and focusing on how to best use JUnit. I am amazed at how well this is pulled off, as I had a discussion with the main author debating certain paragraphs that conflict with TDD practices without even realizing he was on my side.

I remember these discussions, and wondered at the time whether I'd need to apologize for portraying JUnit as something other than a TDD tool. I'm happy to say that more people have appreciated that than had something negative to say about it.

Still, you can't please everyone all the time...

The only negative aspect about this book, in my opinion, is that it does not cover TDD. Being a TDD practitioner myself, that let me down early on as I was expecting hard and fast rules based on testing first and solutions mandating no implementation logic at all. I wanted hardcore JUnit for TDD and this book was teaching me how to use JUnit.

Well, there are hardcore JUnit for TDD books out there, so I wasn't really interested in writing another one. Who I am to do a better job at that than Johannes Link or Dave Astels? All the community would get is another polemic on TDD. I wanted JUnit Recipes to complement the current JUnit literature, and not compete with it.

Incidentally, JUnit Recipes indeed covers TDD. It introduces the topic, refers the reader to other works on the topic (both online and in book form), then weaves TDD discussions into at least half the recipes. What I'm most proud of is the way the book does not try to sell TDD. Brian Marick highlighted this in his keynote at XP/Agile Universe 2004 as a sign that TDD is moving into the mainstream as a programming practice. I suppose I should feel good about the reviewer's comment: the way I included TDD into the book was so subversively unobtrusive that he didn't even notice it. Good!

jbrains on 01.26.05 @ 02:35 PM ET [link]

CFP: Agile 2005

If you are interested in submitting a tutorial for Agile 2005, the newly-merged conference that replaces XP/Agile Universe and Agile Development Conference, go to agile2005.com and choose the Tutorials page. We look forward to your submissions.

Also, if you are interested in reviewing submissions, please e-mail me. I'm looking mostly for people who have been reviewers or presenters in the past, but not exclusively so.

jbrains on 01.21.05 @ 07:05 PM ET [link]

I wish I'd said it

We, the test-infected, are frequently challenged by people who don't want to add or expose code "just for testing". I had always used rather long-winded arguments that generally included the idea that testing is valuable enough to be worth the perceived negative design effects, and that one could eventually refactor towards a design that is both testable and uses only the code that the production system uses. These people generally throw "YAGNI" back in our face.

Well, Ron Jeffries has honed his answer, and I wish I'd said it first:

I refactor now for tests, because I need tests now, not because I want the code to be testable.

jbrains on 01.18.05 @ 09:50 PM ET [link]

The most exciting progress?

According to Cem Kaner, respected leader in the testing community:

[I]t is imperative to distinguish between unit tests and system tests. Unit tests are almost always automated, and it makes a great deal of sense to create a large pool of change detectors. I think the recent advances in unit testing (Astels, 2003; Rainsberger, 2004) have been the most exciting progress that I've seen in testing in the last 10 years.

Cem cites Dave's Test-Driven Development: A Practical Guide and my JUnit Recipes. It is certainly satisfying to see a couple of Canadian guys making such an impact in the community.

Thanks to Mike Bolton for bringing this to my attention. You can read the entire paper here.

jbrains on 01.12.05 @ 02:16 PM ET [link]

Michael Feathers reviews JUnit Recipes

Michael Feathers recently added a review to amazon.com for JUnit Recipes. In it, he wrote:

J.B.'s advice is very good. It goes far beyond the mechanics of JUnit and its extensions. It extends to very direct concrete advice about testing. I recommend that everyone who uses JUnit get a copy. If you are like 90% of the JUnit users out there, you use JUnit but you aren't really using JUnit; not in the way that you will after reading this.

You can read the entire review by searching for JUnit Recipes at amazon.com. You can also find a review of Michael's book, Working Effectively with Legacy Code at masterprogrammer.info.

jbrains on 01.11.05 @ 06:10 PM ET [link]

CUSEC this weekend

I'll be appearing at CUSEC, the Canadian Undergraduate Software Engineering Conference, in Ottawa, Ontario this weekend. The conference runs at Carleton University, which I have not seen in almost fifteen years. The conference runs Friday 1/14 to Sunday 1/16 and registration is still available at Cdn$55.

The Ottawa-area XP user group, led by Dave Rooney, will be meeting informally Thursday night (1/13) at a pub somewhere in the city. I don't yet know the details, but you can find Dave through Google and ask him directly.

I'll be delivering a keynote address (Friday at lunch) talking about differences between writing software in an academic setting and in "the real world", and while this is a well-trod topic, I think I have a few unusual insights to share. Certainly, the audience will be the judges of that. Alistair Cockburn will also be delivering a keynote at the conference, so there will be strong Agile presence. I look forward to that.

I will also sit on a panel (Sunday afternoon) and discuss something wonderful and interesting, although I confess I don't yet know what. That's the fun about panels: the spontaneity of them.

I really enjoy talking to students, especially finding out about their experience (if any) with Agile software development. It's encouraging to see them exposed to Agile concepts before any other software principles have had much of a chance to galvanize within them. I would dearly enjoy working with graduates, helping them make the transition from school to industry, providing them with the kind of training they get in dribs and drabs their first year or two on the job. I hope that this conference will give me the opportunity to find out what these students feel they're missing as they set out into the cold, cruel world.

If you bring your copy of JUnit Recipes to the get-together Thursday night, I'll sign it in exchange for one beer. No limit!

jbrains on 01.11.05 @ 05:53 PM ET [link]

When to fake? When to mock?

In working with Pat Welsh I had occasion to describe in a rather pithy way when to fake and when to mock, so I thought I'd share that with you.

To be clear, I mean "mock" in the sense of interaction-based testing with mock objects, and I mean "fake" in the sense of state-based testing with fakes or stubs. Google if you need a stronger definition of those terms, but they suit me for now.

So then, I want to test some object in isolation from the rest of the system. In broad terms, I need to write tests to answer two essential questions:

1. Am I using the objects around me correctly? Am I invoking the right methods at the right times with the right parameters?
2. Am I reacting to the objects around me correctly? Do I handle errors reasonably? Do I respond well to the answers they send me?

For the first kind of test, I generally mock; and for the second kind of test, I generally fake.

Put another way, I lean on interaction-based testing to verify how my object talks to its collaborators; but I lean on state-based testing to verify how well that object listens.

jbrains on 01.03.05 @ 08:48 PM ET [link]