Years ago, after I finished college but before I started working professionally with software, I spent a couple years working as a paramedic. I learned a lot from that job, not least about interacting with people who really, really don't want you in their lives.

One of the calls I remember most vividly happened around three in the morning, not long after schools had let out for the summer. A group of recently graduated high school girls had rolled their Ford Bronco on the highway. When we arrived an engine company was on scene, busily cutting the remains of the car into fun size Bronco strips. I followed the trajectory implied by the hole in the windshield and found my patient, the driver, on the pavement some distance from the car.

Yesterday I wrote about Wapcaplet, which is really little more than a Rails patch that didn't get accepted, but that some of us think Rails actually quite needs. To that end I submitted a second patch, which does the same thing but, by default, outputs a warning rather than raising an exception. I also included some methods for modifying the behavior on ActionController::TestCase. Specifically, if you want to ensure your tests aren't broken:

ActionController::TestCase.treat_parameter_type_warnings_as_errors

Or if you, like Pierre, don't care:

ActionController::TestCase.ignore_parameter_type_warnings

I don't know if these changes will make the behavior of the patch palatable enough for the core team to commit it. We'll see. After creating the ticket I considered pulling the new behavior back into Wapcaplet; I've decided not to for a few reasons:

• First and foremost, no one pays attention to warnings. I can't count the times I've preached myself blue about eliminating compiler/interpreter warnings, to little or no effect. I recently broke the builds for several projects by deleting a method that had been deprecated for a year and half, and which generated a fairly annoying deprecation warning on every build for every project that used it (keep in mind that at Pivotal projects will build many times a day).

• Any patch applied to Rails will affect every Rails project that upgrades. I believe people should fix their broken tests, but I accept that this change will break a lot of tests. I can accept warnings as a way to show people what may be broken without bringing the world down on their heads. Wapcaplet, on the other hand, is entirely opt-in; no need to handle users with kid gloves.

• I believe that a test failure is the right behavior. We're talking about broken tests, they should act that way.

Remember, the lion ate Pierre.

Imagine for a moment that you run a big, important company. It's important to you that your big, important company be successful at promoting, manufacturing, and distributing your big, important product, so you have decreed that the company must show a profit each and every quarter. In fact, your internal accounting software enforces this. For example:

describe "QuarterlyReportsController#create" do
  it "should reject quarterly reports that show a net loss" do
    post :create, :quarterly_report => { :net => -100 }
    response.response_code.should == 400
  end
end

Ignoring the somewhat misguided domain requirements, this test is wrong because it probably won't fail when it should. It's an example of a problem in Rails controller testing that bites everyone sooner or later.

I'm not sure a person can name a law after himself, but if I had a law I would want it to be this:

Any non-additive change to non-test code that causes no test failures is a valid change and does not reduce the correctness of the code.

I recently published the article There is no Agile, in which I stated that the principles of 'Agile' are nothing more than "a collection of good ideas, based on years of collective experience, for improving how we do our jobs." As an example, consider testing. Thorough testing is a ubiquitous principle of 'Agile;' thus, by logical extension, writing tests is a fundamentally important part of writing software well.

In short, if you write software, and you're not writing tests, then you're not doing your job.

On occasion, someone will ask me what I do or, more commonly, ask me what Pivotal does. The title on my business card says "Agile Developer," which nearly inevitably leads to one of a few reactions, almost all of which boil down to this:

"What exactly does Agile mean?"

You know what? It's a good question. And, after thinking about Agile for several years now, here's my answer: Agile originally was, and still is, a marketing term.

Allow me to explain.

Here's an interesting mental exercise that recently I've found more and more valuable:

1. Test drive your code (duh).
2. Before each time you run your tests, no matter how small the changes you've made, ask yourself why the tests will fail. Don't just gloss over this; be explicit. Say it out loud or write it down, if that helps. If you have a pair, tell your pair.

You might be surprised how often your assumptions turn out wrong. And, you might be surprised what you learn when you explicitly state those assumptions and then have to justify them when they do turn out wrong.

If you don't test drive, or you don't always test drive, (and you're still reading), ask yourself this: what happens those times when my assumptions are wrong and I don't have tests to protect me?