As part of his talk on integration tests J.B. Rainsberger talked about how contract tests can be used to test the interaction between classes when using a mockist approach to developer testing. He wondered aloud if it would be possible to write these kinds of tests using abstract classes and JUnit 4. The answer is yes, with some caveats, as I demonstrate in the screencast below. Enjoy!

EDIT: If the embedded screencast below doesn't work for you, try this link.

The quality of code is a reflection of the environment in which it was created. Chaotic environments usually create chaotic code. Professional environments usually create clean code. In my experience, it's one of the most reliable metrics that you can check before taking on a new client, employee or employer.

So ask to see code. Scan through it. Try to build and deploy it. Try to write a test. It only takes a few minutes and you can learn a lot.

It wasn't because I was used to vim. I wasn't. In fact, aside from editing configuration files through ssh for the occasional sysadmin work I'm call upon to do, I'd hardly ever used vim before.

I started to investigate vim because I had hit a productivity plateau with TextMate. I had learned the majority of the useful shortcuts. I had installed all kinds of bundles, and even made a few. But I still had moments where I thought to myself "I'm wasting time with this", and I had no clear way to make them better.

I started to think that this was holding me back, not in the actual time it was taking, but in the way it affected how I write code. Programmers love efficiency. They tend to repeat actions that are efficient, and avoid those that aren't. As a result, your development environment has a direct effect on how you write code and what code you write. It encourages efficient actions and discourages inefficient ones. The problem is, what's efficient in your editor might not be the best thing for your codebase.

I wondered how I would write code differently if all my modifications had zero cost. If I could add methods, remove classes, rename variables and add new statements in the blink of an eye, I would make different choices about how I code...I don't think it would just be the same thing done faster. I might start writing more exploratory tests. I might use inline assertions more often. I might favor a failing test over firing up a debugger more often.

So I started worrying that inefficiencies in my work environment were encouraging me to take an approach that was, overall, less optimal. This has lead me to some pretty serious thought about what a truly optimal environment would be like. So far, I've come up with four properties of an ideal programming environment:

1. Actions are accessible without switching contexts
2. Feedback is immediate and relevant
3. The environment is self documenting
4. The environment is easily evolved

So the reason I switched from TextMate to vim, is that I think vim gets me closer to an ideal environment. Will it get me all the way there? I don't think so. I do think that I'm already more productive using vim (even after just a month of learning it) than I ever was with TextMate...and I'm still learning. I also think it's going to be a very long time before I hit a productivity wall like I did with TextMate. There's just so much to learn in vim.

At the request of a former employer here's a tail recursive version of the prime factors kata in Ruby.

    def generate(n, factors=[])
      return factors if n == 1
      new_factor = (2..n).find {|f| n % f == 0} 
      generate(n / new_factor, factors + [new_factor])
    end