Free Association

Over time, good programmers build up a library of working code which gets ported from project to project.

Having a library of test code makes this even easier. Instead of messing around with the code, port the test code first. It’s much more fungible.

First, disclaimer: I’m neither a Rails expert, nor skilled at production coding.

That said, I’ve been immersing myself in Ruby, Rails, and if you’re a scientist and engineer who also codes, you might want to consider taking a few weeks to immerse yourself.

Here’s why.

Ruby is an easy language to learn. If you’re well-versed in c++ or Java, or understand how to write object-oriented C, you will pick up Ruby very quickly.

Rails is well-engineered. When you’re on track, Rails is a joy to use. It’s not the be-all, end-all, and it’s going wax and wane (just like Java), but for now, it’s really shining brightly.

Even if you don’t use Ruby or Rails again, the odds are you will learn techniques you can use in your own coding.

For example, test-driven development (TDD) is practically baked in to Rails. Learning both how to code using TDD, and how TDD is baked in are both good lessons.

The received opinion in the software engineering test driven development community is “never test your framework.” This is good advice. And like most good advice, there are exceptional reasons why framework testing might be appropriate:

1. If the framework is undergoing rapid development and is not well-covered in tests, ensuring the framework acts as assumed before running your own tests might save a lot of debugging time later. This is especially true when the API is changing fast.

2. When you don’t understand exactly how the framework behaves, a few tests will help clarify what’s going on. For example, a recently popular CSS framework “decided to be helpful and sneakilly [sic] stuffed jquery into the minified <framework>.js file. Everything worked fine except the ajax:whatever call backs when using remote => true.”

3. I forgot reason three, which is annoying because I started this blog post with three reasons in mind.

Where to test a framework

Some guidelines:

• If it’s mission critical, have a small, separate suite of tests which run independently.
• If it’s for clarity, or for watching something liable to change in the future (such as the ongoing webrat versus capybara matchers issues), drop a framework test right in with a particular spec.

There is a fine line here, easy to cross, but it’s also a line as much in the eye of any particular beholder. That is, when and where to add a few framework tests depends a lot on the developer’s opinion.

Here’s an interesting observation I’ve made as a result of reading (over the last 10 years) the pros and cons of test driven development (TDD). The discussion seems to eventually get this point:

• “TTD is a crock. I just don’t see the need to fully test everything. It’s a waste of my time.”
• “TDD is awesome. We found TDD really helped speed up our development and ship better product.”

Feel encouraged to draw your own conclusions.

There’s a guy hijacking the comments section at a popular WordPress plugin site to promote his opinion on code formatting.

Sets my teeth on edge it does!

Here’s some basic rules:

• He or she who writes the code calls the formatting. Unless…
• Code contributed to a larger project should adhere to the project’s formatting, and …
• If you’re writing the checks, you get to specify the formatting system.

Super easy!

I had to let a coder go once because that person insisted on using an outre formatting system (for c++), and the code wasn’t good enough for me to deal with it. That is, I needed to rewrite and reorganize the code after delivery. Extensive discussion resulted in more extensive discussion… waste of time.

Note: Whenever possible, I site read code, so I depend on the geometric shape of code blocks to give me information. That’s me, that’s what I do. You can do whatever you want.