July 2009 Archives

Does the expected value of a unit test assertion go on the right or the left side?

Option 1: Expected Value on Left

    assert "Aaron Oliver" == user.fullname()

Option 2: Expected Value on Right

    assert user.fullname() == "Aaron Oliver"

Yes, it’s a bikeshed issue, but I think it’s worth discussing. Mixing conventions is confusing.

I think option 2 is closer to how we speak and think about test assertions:

Verify the result is what was expected

However, I’ve been doing option 1 since my Java days, I think because that’s how JUnit wants it.

What’s the best way?


| Comments

Gary Bernhardt’s screencast of Python mocking library Dingus is worth a look both for the demo of the Dingus “mock almost everything” strategy as well as Gary’s mad vim skills. It’s been mentioned before, but is worth repeating: you can always improve on how you use your tools.

I’ve downloaded his set of dotfiles (.vimrc, etc), and am slowly working my way through it all.

Here’s the whole video. Kinda soothing to hear the constant clicking of keys as code appears on the screen.

Dingus: A recording mock/stub library for Python with automatic isolation from Gary Bernhardt on Vimeo.

I was poking around with Selenium and wanted to write some assertions about a page not being a 404. I did a quick Google search, and came upon a thread where a maintainer kept pressing people for “a valid use case” for adding an explicit method to test HTTP response codes. His logic being that one could test for various page elements to see if it’s a 404 or not.

Still no meaningful use case has been provided. Instead of checking the HTTP response you should make assertions on the content of the page - this is what the user faces and not the codes.

This is true. One could check DOM elements to see if the page was found, but it feels better to have a simple yes or no answer to “Is the page even there?”.

Doing it the current way might look like this, where your company’s pages have h1’s with class “logo”.


This is perfectly ok, but it’s little tricky to know exactly what’s going on. My brain reads that as “Check to see if our (hopefully) universal h1 class value appears on the page, and if it does, assume it’s not a 404.”

Here’s what the same assertion might look like, but using the requested function from the thread:


This is much cleaner and more expressive: “if it’s a 404, fail the test. Don’t bother checking anything else”.

They’re both a single line, and not too complicated, but the second version feels better. It expresses the idea more clearly.

Writing code is communication. The tough part is that we write for machines and people at the same time. I think it’s a good idea to throw humans the occasional bone, and make things as humane as possible.

Grow or Die

| Comments


Programmers often emphasize mastery, wisdom, and skill. We’ll even say “I love to learn new things”.

Awesome. High five. Learning new things is good, but take care to avoid becoming just a sponge. Growth is important, and different from learning.

I can learn Scala, and I can learn Django; but the mere act of learning doesn’t really help me grow as a creator of awesomeness. I need to do that on my own.

My brother is an architect by trade, and we often talk about how designing buildings and making software are the same. In my previous post, he pointed out Bruce Mau’s Manifesto for Growth.

Bruce’s list is excellent reading. Here are some of my favorites:

Allow events to change you. You have to be willing to grow. Growth is different from something that happens to you. You produce it. You live it. The prerequisites for growth: the openness to experience events and the willingness to be changed by them.

Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces — what Dr. Seuss calls “the waiting place.” Hans Ulrich Obrist once organized a science and art conference with all of the infrastructure of a conference — the parties, chats, lunches, airport arrivals — but with no actual conference. Apparently it was hugely successful and spawned many ongoing collaborations.

The target audience is visual designers (so ignore the one about “avoid software”), but the similarity to how our brains are forced to work as programmers is impressive.