It's done! It's out. And I couldn't be happier.

As part of writing writing Continous Testing: with Ruby, Rails, and JavaScript, I had the opportunity to talk to a lot of people about what Rod and I were doing, and what they thought of it. Most of the people, once introduced to the idea, thought it was so obviously good that there just wasn't any reason not to follow this practice. By running your tests on every change, you create a tight feedback loop that makes it so much easier to find bugs and get a better understanding of what your code is doing. I'm really proud of what we've done with this book because I think the techniques we discuss in it will really open this practice up to a wide range of developers and projects.

Node.js is supposed to be all about an asynchronous style of programming. Rather than executing functions and getting results, we use a lot of first order functions and callbacks to do things asynchronously. Here's an example of this style from the djangode project. makeApp is a function that takes an array of arrays that are regex/function pairs. Some of those function invoke other functions (such as setTimeout) that take other functions.

I find this kind of code rather tricky to test, and to reason about. Functions nested four levels deep makes my spidey-sense tingle. A good technique for cleaning it up can be extracting those anonymous functions into named functions, but if there are variables that are shared across scopes, that can get a little messy too.

However, I really like Node.js and the approach they've taken, simply because the asynchronous style is a rather elegant (if not new) solution to the kind of performance problems you encounter when working with single threaded code. Blocking operations, IO is particular, can really kill your app, and using threads to avoid blocking can lead to code that is nigh-impossible to test or reason about...so the Node.js asynchronous style merely being a bit tricky is a huge upgrade.

However, I haven't found myself really digging using that style all the time. I generally prefer a functional style when working in JavaScipt. In my opinion, function composition is a huge advantage in JavaScript, but callbacks generally don't have return values, so they're harder to compose. In fact, it really only seems appropriate to use callbacks when I would otherwise be tempted to use a thread to avoid onerous blocking IO. Otherwise, I like to stick a more functional style and stay away from the asynchronous code.

I gotta say, this is pretty neat.

You know, just in case you forget what Huffman encoding is.

Twitter is a personal denial of service attack. If you want to steal someone's productivity for a day, just troll them on Twitter.

Oh, and I'm not posting this on Twitter, because I have better things to do than defend my argument.

After reading Tim Ottinger's excellent article on the meaning of "sustainable pace", I couldn't help but pose a question on Twitter. 140 characters just isn't enough to clarify this question, and so we move to the blog to fill in the details.

Let's assume that we have a customer (likely a proxy) who wants a development team to work overtime to complete a task. Let's further assume that this is really a task, that is, a day or two of work, to be done on a weekend or during a couple of really late nights. He thinks that this task requires an additional level of effort, and that working late is worth the sacrifice (to both morale and the later productivity of the team). To clarify, the customer isn't providing the budget for this project and he isn't any more of a stakeholder than the developers.

Let's also assume that we have a development team that has a decent understanding of the business concerns of the project. Their opinion is that this task is no more urgent or particularly valuable than anything else they've been asked to do. To use the terms from Tim's article, they don't think it's necessary to come to the rescue in this case.

My question is this: If the customer proxy forces strongly suggests that the development team work overtime to complete the task, even though the developers think overtime is unwarranted for this task, is that unethical?

On the one hand, the customer is likely benefiting from the delivery of additional features, and the morale of the team may be damaged. If this is 'the last straw' for a key developer that can easily find work elsewhere, the customer may have cost the company dearly to benefit himself. Even if the customer truly believes that the sacrifice is worth the benefit, is he caught in a conflict of interest?

On the other hand, what if the customer is right? A good development team understand the needs of the business, but you would think that the customer would have a better understanding. Disagreements happen. Our goal is always better communication and understanding, but there's little point in having an 8 hour meeting to avoid 12 hours of overtime.

What say you, Internets?

"Continuous Testing with Ruby" is now available as a beta book on pragprog.com! This is the first beta, so there's still more to do, but Rod and I are very happy to have it out there so we can get some feedback.

Continuous Testing starts with a simple idea: Run your tests all the time. I think this book does a great job of communicating all the incremental improvements to that idea that Rod and I have come up with over the last few years. From using CT as an alternative to debugging, to finding ways to automatically check other project artifacts (like documentation and seed data), once you get hooked on having instant feedback for everything, you start to find all kinds of ways to apply it.

Probably the biggest effect, however, is how CT helps you write better tests. One of the points we made in the book goes like this:

An old axiom of Test Driven Development states that the tests test the correctness of the code; while the code, in turn, test the correctness of the tests. The tests also test the design of the code—code that’s hard to test is usually poorly designed. But what tests the design of the tests? In our experience, Continuous Testing is an effective way to test the design and overall quality of our tests...running our tests all the time creates a feedback loop that tells us when tests are misbehaving, as we create them. This means we can correct existing problems faster, and prevent bad tests from creeping into our system in the first place.

I'm very proud of what we've done with this book. I think it will be really valuable to anyone who's been writing automated tests and wants to get more out of them. I've been a doing TDD (and then BDD) since about 2003. My interest in continuous testing began in 2006 when I thought about all the time I was wasting figuring out which tests I needed to run after a change. After that, I wrote Infinitest, and now Continuous Testing with Ruby. I'm greatly looking forward to see where we go from here.

After having spent a long time trying to run javascript tests with Rhino, I've finally found something better. Rhino was never really fast enough for me. Spinning up the JVM just takes too long when you're running your tests continuously. A few seconds really makes a difference when you do something hundreds (thousands?) of times per day.

On top of that, testing frameworks like ScrewUnit (aside from being abandonware) have scoping issues that make tests very brittle...unless you run each one in it's own process...again back to the JVM startup problem.

Recently, I started playing around with the Jasmine testing framework for Javascript. It was really nice, but I wasn't convinced it was really going to solve the problems I was experiencing since they were mostly due to global namespaces and Rhino.

Enlighentment came, however, when I tried running Jasmine tests from within Node.js, using a patched version of mhevery's jasmine-node module. If you don't know, Node.js is a Javascript runtime environment based on the V8 engine. It's actually designed for server-side development, but I wondered if I could use it to run tests for my in-browser javascript. The answer is mostly, but the results were very compelling and I'm now doing this on all my web application projects.

Firstly, here's an example project that shows how I set things up.

To understand what's going on here, lets begin at the html. In index.html, we're not doing anything fancy. Just a few tags to load jquery and the javascripts in our app: