Avoid coupling test names to implementation

In our first iteration in the JavaScript Code Retreat, we worked on the rules to tell if a cell goes on living or if a new cell is created having the restriction of not using conditionals.
So we used two very small functions: goesOnLivingWith and isCreatedWith that accepted the number of neighbors as a parameter.

We implemented them using TDD and end up with the following tests:

	describe("rules", function() {
	describe("rule to go on living", function() {
	it("dies with more than 3 neighbors", function() {
	expect(rules.goesOnLivingWith(4)).toBe(false);
	});
	it("dies with less than 2 neighbors", function() {
	expect(rules.goesOnLivingWith(1)).toBe(false);
	});
	it("goes on living with 2 or 3 neighbors", function() {
	expect(rules.goesOnLivingWith(3)).toBe(true);
	expect(rules.goesOnLivingWith(2)).toBe(true);
	});
	});
	describe("rule to be created", function() {
	it("is created with 3 neighbors", function () {
	expect(rules.isCreatedWith(3)).toBe(true);
	});
	it("is not created with less than 3 neighbors", function () {
	expect(rules.isCreatedWith(1)).toBe(false);
	});
	it("is not created with more than 3 neighbors", function () {
	expect(rules.isCreatedWith(4)).toBe(false);
	});
	});
	});

view raw conwaysRulesTestsInitial.js hosted with ❤ by GitHub

The main problem with the names of these tests was that they were tightly coupled to the conditions in the rules we had coded:

	var rules = (function () {
	function hasThreeNeighbors(numberOfNeighbors) {
	return numberOfNeighbors == 3;
	}
	function hasTwoNeighbors(numberOfNeighbors) {
	return numberOfNeighbors == 2;
	}
	return {
	goesOnLivingWith: function (numberOfNeighbors) {
	return hasThreeNeighbors(numberOfNeighbors) ||
	hasTwoNeighbors(numberOfNeighbors);
	},
	isCreatedWith: function (numberOfNeighbors) {
	return hasThreeNeighbors(numberOfNeighbors);
	}
	};
	})();

view raw conwaysRules.js hosted with ❤ by GitHub

So we refactored the tests names to improve that:

	describe("rules", function() {
	describe("rule to go on living", function() {
	it("does't go on living because of overpopulation", function() {
	expect(rules.goesOnLivingWith(4)).toBe(false);
	});
	it("does't go on living because of underpopulation", function() {
	expect(rules.goesOnLivingWith(1)).toBe(false);
	});
	it("goes on living", function() {
	expect(rules.goesOnLivingWith(3)).toBe(true);
	expect(rules.goesOnLivingWith(2)).toBe(true);
	});
	});
	describe("rule to be created", function() {
	it("has enough neighbors to be created", function () {
	expect(rules.isCreatedWith(3)).toBe(true);
	});
	it("has not enough neighbors to be created", function () {
	expect(rules.isCreatedWith(1)).toBe(false);
	});
	it("has too many neighbors to be created", function () {
	expect(rules.isCreatedWith(4)).toBe(false);
	});
	});
	});

view raw conwaysRulesTests.js hosted with ❤ by GitHub

These new names are much better because they describe the rules focusing in their behavior without getting into details about their implementation.

Avoiding coupling test names with implementation by expressing just behavior will make test names more durable since they won't have to be changed if the implementations undergo any changes.