Tddium Isolation

We’ve been busy adding features to Tddium in the last few days, including MySQL 5.1, Sqlite3, and Spork. Redis and MongoDB are implemented and about to be released. More importantly, we’re now using Tddium internally on a regular basis and I have to say it is a big step forward. Why? Well it certainly is nice to have a fast, hosted test environment, but the big reason for me right now is isolation. Each test script runs in its own thread with its own isolated environment: it gets its own Postgres, MySQL, or Sqlite database; it gets its own Spork DRb for rspec or cucumber; it gets its own fresh set of loaded modules. In short, each test script runs in its own complete environment.

The fresh set of modules is a great example of why isolation is a Good Thing. If I run rake spec locally, modifications to the environment by one test can be visible to the next. Yes, tests shouldn’t pollute the environment, but tests can have bugs, too! For instance, if I have two modules, A and B, that both need Syslog but only A properly requires the Syslog module, if I’m unlucky the tests for A will get run first and so the Syslog module will be loaded when the tests for B are run. With Tddium this doesn’t happen: each test script gets a fresh environment and so the second set of tests will fail. I could fix this problem locally by implementing a rake target that ran each script separately to avoid this particular problem, but then I’d have to pay the penalty for loading the whole Ruby environment each time and my laptop already runs hot. Moreover, this approach doesn’t address the isolation problem for databases and other resources. Tddium takes care of all of these problems and gives me the parallelism to make it fast. My laptop is also a lot happier — or at least a lot cooler…

Post a Comment