Introducing TestBench


The Eventide Project is happy to announce the release of TestBench, the principal test framework used in the Eventide stack and by the Eventide community.

With the release of the TestBench docs, TestBench advances to v1.0.0.0, and becomes officially supported by the Eventide Project and community.

Users of the Eventide Project are already familiar with TestBench, but we invite the Ruby community at large to give it a try.

TestBench is just a plain old context/specification style testing framework that we’ve been familiar with since the dawn of this testing style in the mid-2000s, but it’s significantly lighter.

context "Some Context" do
  test "Some test" do

  test "Some other test" do

More about writing TestBench tests at:

TestBench also imposes no special runtime semantics, and requires no special runner executable other than Ruby itself. A TestBench script runs the way it reads: like a Ruby script.

> ruby test/automated/some_test.rb
Some Context
  Some test
  Some other test

More about running tests at:

Check it out the complete docs at:

Nathan Ladd started working on forerunners of what would become TestBench early in the Eventide Project’s life. Over the past five years, it has been put through its paces in countless projects, and is the test framework used in 50+ libraries that make up the Eventide Project. It’s also the tool often used by teams that adopt Eventide for their own work.

TestBench came into existence in response to the growing distance between the directions the tools we had were going in and what we wanted from our tooling. So, we outlined the values that we wish a testing tool would reflect, and Nathan took the lead on building it. After a handful of experiments and interim releases, it’s ready for public consumption.

TestBench isn’t for everyone. It’s a “by us for us” kind of tool, where the “us” is developers with decades of experience in testing, design, process, methodology, automation, and test-driven development.

It offers none of the typical safety affordances available in test frameworks that help keep new developers out of the weeds.

It counts on a developer’s ability to design tests so that they’re isolated, rather than count on test framework features for things that can be solved by not creating isolation problems to begin with. TestBench leverages Ruby’s lexical scoping and its existing script execution semantics, rather than before and after blocks. It doesn’t do rollbacks on database transactions, but expects developers to isolate data by controlling the identifiers used when data is stored.

TestBench won’t break backward compatibility with either existing tests or with your editor. There’s very little to break. The TestBench API is just a handful of methods.

It’ll work in every editor without creating plugins because the basic runner is just Ruby. TestBench tests are just plain old Ruby script files. Tests run the way they read.

And while we say that TestBench isn’t for everyone, we’ve never seen anyone, no matter their experience level, fail to understand and use TestBench with very little effort.

If TestBench has a slogan, it would be: It’s Just Ruby. And if you like that kind of thing, then you might like TestBench! Have a look and give it a try. And if you want to pick the brains of TestBench users and developers, reach out on the test-bench channel on the Eventide Project Slack.