Red-Green-Refactor-Commit (Why Red?)

When I was first introduced to the TDD framework, Test Driven Development. My first question was “Why red?” Apparently, it quite a common question…

The reason is actually quite simple, we are writing test/specs to check the logic of our code. But there’s no reason why we won’t make mistake when writing the test/specs itself. The red test is the test for the logic of the test/specs. Hmmm, if a test/specs is broken down well, there should be low chance for mistakes. Well, Murphy’s law applies. It’s better to play it safe.

Here’s an example, I came across recently showing how important a red test is:

When override the equality instance method of Moo Class in ruby, here’s a spec to test to return false for different types.

it “is not equal for different types” do
moo =,2)
expect(moo.class).to_not eq(Object.class)

Seems pretty straightforward, can you spot what’s wrong at the first glance? This class will always return green. It doesn’t matter if you overwrite the equality method in Moo class, it will never be called in this case.

With a red check, we can easily spot this subtlety. Happy testing. :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.