Our house has been clean and orderly and…quiet.

We looked at two rescue dogs today. One is a three-month old terrier – Rottweiler mix puppy named Darla. The other is an eight year old Weimaraner named Skeeter.

We’re considering adopting both of them.

We might be nuts.

Complexity

The code you just wrote would be so much easier to test using system-level testing. For example…

• The setup and teardown would be 10x the test code.
• There’s too much interaction with multiple data stores or third-party vendors.
• Your dev boxes or CI server don’t all have the necessary technology installed.

These are rational reasons to not write unit tests for new code. You’re fine.

Simplicity

But sometimes you don’t write unit tests because the code you just wrote is so darn obvious.

It’s really simple. It’s straightforward. It’s nearly trivial. Why both writing unit tests for it?

Well, I’ll tell you why you should test it. In fact I’ll give you three reasons.

It might not be quite so obvious. We’re very good at fooling ourselves in an infinite number of ways. “When this code executes, we know XYZ has already been done.” “If this function call returns without an exception, we know the other server is up.” “If the key exists, it will have a value.”

But maybe one of your assumptions is wrong!

• You didn’t consider a corner case.
• You didn’t stop to think what would happen if your unreliable piece of shit poorly constructed cloud network has a transient between point A and point B.
• You didn’t realize that when the XYZ wrapper initializes, there’s a brief period when the key exists but the value is empty.
• Etc.

At least one of your assumptions may not be true. Wouldn’t it be better to find out in a unit test?

If the code is so easy, writing the unit tests should be easy. If your new chunk of code is trivial, then writing the unit tests should be easy.

Oh, it’s not easy? Because constructing the arguments isn’t so easy, or concocting the expected results is a little tricky? That should tell you something, pardner.

Clunky code unit tests can expose bugs in unexpected ways. When I test “obvious” code, I use a technique I call “clunky code.” (I’m not good at naming things because I’m not in marketing.)

It’s simple: If creating the expected results requires mimicking the code under test, I deliberately create the expected results in the most awkward, different, and simple possible way. So the unit test is the negative inverse reciprocal of being a cut-and-paste of the code under test.

Here’s an example. I had a function that established an FTP connection, and returned a list of (filename, creation date) tuples from a directory. The low-level FTP code had been used for months, but the results creation was new. It had regex and slice extraction in a loop, and converted “mmm dd hh:mm” into “mmm dd yyyy”. No big deal, right?

I coded the test to concoct the expected results in a butt-simple loop with different slice code. And guess what, I found a couple of bugs. One slice was brain-dead wrong, and another slice’s start and end indexes were both off by one. I found those bugs only because I computed the expected results differently.

I’ve had other instances where my clunky unit test code exposed bugs in functions that weren’t “official” test targets. I was pleasantly surprised to find the other bugs and squash them dead.

So, test your obvious code!

He explained that I experienced a bug in their dynamic image configuration. When you instantiate a VM, a number of things happen behind the scenes to the base server image. It’s not as simple as copying a directory tree from A to B. A bug was introduced into their code, and they caught the bug and fixed it, but not before it bit some users.

So, Rackspace didn’t intentionally change the server image this time. I apologize for drawing that conclusion.

My November 2011 post about mutating server bits is still correct. We talked about Rackspace’s challenge in balancing “simplicity of use” vs. “power users’ information needs” when a server image changes.

22 days ago, I provisioned a staging system with Ubuntu 11.10. In upgrading from 11.04, I had the typical difficulties — e.g., removing 11.04 package workarounds, and upgrading some software that we built from sources. When I finished, my Fabric script provisioned my 11.10 servers, and I wouldn’t have to futz with it again until we advanced to Ubuntu 12.04.

So imagine my surprise when I tried re-provisioning our staging system yesterday, and the script threw an oddball installation failure for PostgreSQL, and all the servers had oddball network flakiness.

What the? Our fabfile.py hadn’t changed. I was still installing on Ubuntu 11.10. In 22 days there weren’t any significant package changes. This was weird.

After a couple of hours sleuthing, going to Rackspace customer support for help, and searching on the web, I found that the Rackspace Ubuntu 11.10 images had mysteriously changed in two significant ways.

Git becomes a git

22 days ago, our script did this without error:

with cd("/tmp"):
    run("git clone git://github.com/ariya/phantomjs.git")

The “run” command now generated a name resolution failure. After some puzzlement, I elected to use a sledgehammer:

with cd("/tmp"):
    sudo("git clone git://github.com/ariya/phantomjs.git")

…and all was well.

Network? You don’t need no steekin’ network

The Ubuntu 11.10 image now has /etc/hosts protected from world read access! It should (and 22 days ago it did) have an access mode of 644 when the server first booted. It now has an access mode of 600.

Surprise!

A hat tip to a Blogsplat post that described this same problem with Rackspace Ubuntu 9.10 images, and which saved me lots of time.

Gah

Rackspace’s “Live Chat” customer support was great. The rep was super helpful, and he & I debugged the problem together in real-time. I can’t get mad at him, because he’s just the poor sod who’s on the customer service front line!

But I am increasingly irked by how Rackspace changes a server image it’s already published. I don’t understand how anyone can think this is a good policy. If there’s a flaw in an image, leave it in place and put up another server image with the fix. Maybe use local version numbers on the server images.

It’s like they don’t realize their customers might use automated deployment, and once they can install and configure version X of server image Y, they expect to have repeatability.

Personality cults are odd. At a conference, I see this most often in the backchannels. Like on Twitter. If Fred tweets XYZ, it probably won’t be RT’d; and if it is, it’ll be RT’d at most twice. But if a community cognoscenti tweets the same thing, it’s RT’d 18 times as a gem of profound wisdom. That this phenomenon is so obvious only adds to its oddness.

I met someone who lives and works in the Galápagos Islands for the Charles Darwin foundation! We had a nice chat. He has fascinating challenges doing data crunching and providing web services down there.

“Pragmatic Unicode, or, How do I stop the pain” — Gah, shoot UTF-32 and UTF-16 in the head. That’d be my vote.

The Celery talk will be interesting. I’ve interacted with Ask online, never met him in person.

Great Keynote speeches. Morning is metaclasses, classes, and subclasses. Should one run away from metaclasses, or view them as just another tool?(Apologies to Edward Teller‘s estate.) The subclassing talk taught me a thing or two.

“If your class has only two methods and one of them is __init__, it’s not a class. It’s really a function.”

Advanced security topics summary: We’re all doing it wrong and we’re all hoseheads.

Lots o’ good ideas and tips about context managers and decorators. I’m going to rip up some code when I return to work on Monday.

Today is a “Python epiphanies” tutorial, and NLTK. More goodness.

If the company asks you to cancel it because now’s not a good time to be out of the office, should you?

Is there ever a good time to be out of the office?

When do you bend, vs. drawing a line in the dirt and saying you won’t cross it?

I’m just asking the question.