Let's write software that people
understand.
The work that Diasparsoft did for us was outstanding. We are now using the software on a daily basis and their work could well have a dramatic impact on the Reds' organization in the near future. —Cincinnati Reds Baseball Club.
Well, I apologize for the last-minute publication, but the final, final, final instructors for Test-Driven J2EE at SD West Expo are complete. Go to this page and follow the instructions. With any luck, they're Too Simple to Break. (I know, I could have added an Ant build, but I'm tired.)
Thank you so much for your patience. I look forward to many beers with you in Santa Clara. See you Monday!
jbrains on 03.13.05 @ 12:45 AM ET [link]We have updated instructions on the web, but we still don't have an Eclipse project file uploaded yet. I'm working with my ISP's support to make that happen.
jbrains on 03.11.05 @ 12:44 PM ET [link]My wife and I are planning an eventual move to Dauphin, Manitoba. (Yes, we've seen Funny Farm, although we were more inspired by Lost in America.) We have already purchased a house there and we plan to go back every six months or so until we're ready to move. I consider it a two-year experiment: if, after two years, we don't like it, then we move elsewhere; but in the meantime, it's cheap livin'.
I'd like to run a programmer's retreat there this summer, likely soon after Agile 2005. Some of you will be going to this conference and others not. If you think you'd be interested in a retreat during which we will write code, play games and think only about programming, then send me e-mail with the words "Programmer's retreat" in the subject line. (This helps you get past my spam filters.) More news as we get closer to August.
jbrains on 03.11.05 @ 07:01 AM ET [link]Yet another win for Learning Tests. It turns out that, ugly enough, creating a FileWriter (in Java) automatically blanks out the underlying file, even if I never actually write anything to it. That's just crappy, but at least I have a test that demonstrates the behavior.
"October" says, about JUnit Recipes...
This is a book that should be on the bookshelf of any Java developer. I just finished implementing a continuous integration system here on my team, and I leave this one out on the corner of my desk. It disappears usually once a day, as the team starts to get up to speed on automated unit tests. I highly recommend it. My only quible with it is a general quibble I have with many things I read written by TDD evangelists: it assumes that the reason organizations don't refactor to support easier testing is laziness, inertia, fear, etc. How about because the system works as is, and trying to sell refactoring of a working system to project stakeholders is a tough sell? How about timelines are tight enough to just to hit the critical must have features that customers are demanding? Yes, I know testing is important. Believe me. However the system has a lot of EJBs that need to be run in container. I've mocked out where I can, where it makes sense, but applying things like Inversion of Control is going to have to be done over time.
I don't remember being a TDD evangelist when writing JUnit Recipes. I tried rather hard not to be, simply saying, "Here's what I'd do if I had my choice. If you can't do that, do this instead." This explains why there are so many recipes for dealing with legacy code that one can't change to bring under test. (For more on this topic, thou shalt read Working Effectively with Legacy Code.) Evidently, here is one case where I failed at my objective.
I don't have the energy to go back and re-read the book, because it's quite big and I have Too Much to Do as it is. When I do, I'll likely be embarrassed by the strength and naivete of some of my opinions about the importance of testability. I likely did a little soapbox speaking, and I apologize for that. My only defence is this: it had to be done.
Today, I counsel people to examine the tradeoffs between refactoring to support testing and testing legacy code as is. In examining the tradeoffs, I try to point out to people a few things:
To the attendees of Test-Driven J2EE at SD West Expo next week, we will be posting a downloadable Eclipse project containing all the dependencies for the first exercise. We will include instructions for installing and running the project, which assumes you have JBoss installed and the JBoss-IDE plugin for Eclipse. If you get that working, then when you update on Monday, things will go much more smoothly.
jbrains on 03.09.05 @ 08:40 AM ET [link]After nearly two weeks of living mostly in IDEA and arguing with the locals about which is better, I have come to the conclusion that one of Eclipse's default settings is wrong.
Run/Debug > Launching > Save dirty editors before launching should, by default, be "Always" and not "Prompt".
jbrains on 03.03.05 @ 09:25 AM ET [link]Contract Tests explain how a class should extend a superclass or implement and interface, so that I don't have to read a bunch of prose to figure out how to do that. Typically, a contract test case class is abstract, then I extend it and implement a creation method or two to return instances of my own implementation of the given interface. That gives me a standard battery of tests I can run to drive my implementation. It might not be perfect (I'll have n failing tests to start) but I prefer it to documentation written in prose.
So if you're delivering something you want me to extend and I need to follow more than three rules, please deliver me some contract tests.
jbrains on 03.02.05 @ 09:24 AM ET [link]