Code in Java, test in Java. With JavaScript, test in JavaScript. Ideally with a test framework that lets you write your unit tests in a way that does not feel contrived or constrained compared to writing production code.
For example, until version 4.0, JUnit required that test classes extend a special class, TestCase, and that test methods start with a special prefix. These constraints felt rather arbitrary (in truth, they were present mostly for technical reasons) and were replaced with annotations in later versions of JUnit.
In contrast, unit testing your production language in a different language (as advocated here, for example) will require you to adjust your mental state every time you switch from production code to unit test code. Instead, I want as seamless a transition as possible, as I’ll frequently switch from one to the other, especially when practicing test-first style development.
The same advice applies when considering Behavior-Driven Development (BDD) frameworks that come with their own language or formalism such as Cucumber and FitNesse. Although those may have value as acceptance test environments, using them for unit testing will slow down the feedback cycle created by quickly going from reading/writing tests to reading/writing production code. I’d even argue that this aspect of their design is a drawback to doing other forms of testing. Although there are not many of them yet, it is worth putting some effort into finding a high-level test framework that works directly in your favorite programming language (one such example for BDD is Narrative).
Finally, notice how proficient you are in your production code? That comes from years of practice. It also comes from a productive development environment. Use those to your advantage.
This is an excerpt of a chapter I’m writing for the upcoming CITCON Chronicles book.
