A History of Build Systems

In my younger days, before I knew any better, many projects I worked on compiled and published their software manually.
You'd type cc and then copy these bits over there and then zip that directory and post it to there.
Eventually, we figured out we could write little scripts to automate all the tedious bits and make it less fragile
and more repeatable.

One day, I discovered the discipline of daily builds and tools like make and my life got a whole lot better.
Make gave us, in Elizabeth's handy phrase "a place to put things".

In Influence: The Psychology of Persuasion, Robert Cialdini describes various techniques for making people do things that, if they were thinking clearly, they would otherwise not do because of lethargy, laziness, or because it would offend their better judgment.

One of those techniques is The Commitment Principle which was used on American POWs to great effect by the Chinese during the Korean War.

I hosted a JUnit Factory presentation a few days ago (you can
watch
it online if you missed it first time around) and spent a fair amount of time talking about the Triangle sample
in the JUnit Factory demo.

Before I move on to spares and strikes, it would be nice to see how the score sheet looks. In
an earlier post,
I claimed that one of the reasons for integrating the UI early is to make sure the domain model will satisfy the
requirements of the user interface. Let's see if it does.

In my previous blog entry, I posted a set of acceptance tests for the first few stories. It's time to start writing the code to pass those tests. I prefer to discover the design through TDD rather than code directly to the customer-facing tests.

I have often written acceptance tests for code that has not yet been written (in fact, I wrote an article about it) but I have never written tests that will work with any number of implementations, each with their own architecture. I don't even know how to go about it, but that never stopped me before...

"scoring a game of bowling" is probably the most common application used when demoing TDD. It's so commonly known among the JUnit crowd that I chose one of Bob Martin's efforts as a demo for JUnit Factory.

The topic comes up about once a year on the TDD mailing list and it just came up again. By an odd coincidence, we just celebrated the completion of a new release of AgitarOne with a trip to Homestead Lanes, so I am all fired up about bowling despite my dismal performance (there was beer involved).

Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

I just wrote a page on our internal wiki with our policy for dealing with build failures. We thought others might find it interesting so I am sharing it here (the links will be broken for obvious reasons).

Executive Summary

There are many reasons why you might not want to fix a failing test right away. Maybe it's an acceptance test for a feature that you haven't written yet. Maybe it's a regression that it's just not practical to fix right now.

There are many reasons why you might not want to fix a failing test right away. Maybe it's an acceptance test for a feature that you haven't written yet. Maybe it's a regression that it's just not practical to fix right now.

1. Test your own code as well as you can
2. Next time someone checks in a slap-your-forehead bug, show them the test that would have caught the bug if only they had run the tests.
3. Show them how to run the tests themselves

It won't be long until everyone will want to have tests.

Most developers will not make the investment until they have seen proven returns. The management challenge is to find the early adopter with the courage and vision to take that first step.

Bruce Eckel weaves together the two hot topics in blogland this week. One is the Humane Interface vs Minimal Interface discussion which pits Java's List API against Ruby's. The other is the "Death of Java" topic.

BTW I often use the Adapter Pattern to wrap a class that seems to need utils until eventually the Adapter grows into a whole new class of its own. I have done this to add utility functions for parsing and xpath querying to org.w3c.Document for example.

The Pragmatic Programmers recommend learning a new language every year. Not because you need to know a whole bunch of languages, but because other languages use idioms that you might not think of using in your everyday language.

I wrote this article for the March 2005 issue of Better Software. Now available for the first time online... enjoy!

I have worked with many testing common organizations where a common pattern is repeated over and over. It goes something like
this — we realize there is more manual testing to do than time available, we decide to automate the testing, and we begin working
on a test harness. Several weeks later, we have the start of a harness, but it’s barely useful and we still have not written any
tests. At this point, we’re behind — so we abandon the harness
and revert to manual testing.

TDD and Agitation
I have been doing Test Driven Development (TDD) for about four years now and agitating for a little less (it's my second
anniversary as an agitator today) and I have thought a lot about how to marry the two testing styles.
A discussion on the TDD mailing list today
(http://groups.yahoo.com/group/testdrivendevelopment/)
finally gave me a name for what I have been doing for a while. The discussion centered around the relative merits of
TDD versus Design by Contract (DbC) and a surprising - surprising to me anyway - number of people said that two
are complementary and that they do both. That's exactly what I have been doing without realizing it. more »

Testing HTML Pages
I started this article intending to talk about a technique we developed for testing Velocity templates but realized that there was enough background material for a separate article on testing html. So, this entry describes how we developed a harness for checking the output from the Management Dashboard. A second entry will talk about how we adapted the harness for testing Velocity templates. more »

Fight Complexity with Complexity
We were using method and class and package names as keys to the various data structures that store test results and coverage data. Agitator told us that if you pass the string "123%%^*abc" to a method that expects a class name, it throws an IllegalArgumentException. "Well, duh!" we said and marked it expected. We added a factory to generate a variety of good and bad class names and got on with the task at hand. more »

Jan 16, 2004

–

Why Is Software So Hard To Test?
Start a conversation with any developer about unit testing and, before long, he'll tell you that automated testing is a fine thing in principle but that his code is too hard to test because .... more »