О граблях и тестах: дублирование кода 16.01.2016

Часто при написании тестов разработчики придерживаются подхода DRY, при котором они стремятся свести на нет дублирование кода. Дублирование кода, конечно, практика плохая, но при написании тестов подходом DRY не стоит злоупотреблять. Код тестов не должен обладать сложной архитектурой, ведь в таком случае разработчик, изменяющий существующий или добавляющий новый тест, потратит дополнительное время на то, чтобы разобраться как функционирует сам тест.

Если вы все таки выделили логику однообразных тестов в отдельную функцию, не следует помещать синтаксические конструкции фреймворка для тестирования, отвечающие за структуру тестового кейса в тело данной функции. Приведу пример:

Неправильно

testSomething("does not matter how to define an array", [1, 2, 3], new Array(1, 2, 3));

function testSomething(description:string, expected_value:SomeValue, actual_value:SomeValue) {
	it(description, () => expect(actual_value).toEquals(expected_value));
}

Код теста, приведенный выше, обладает нестандартной структурой, что плохо сказывается на его читаемости. Многие интегрированные среды разработки при падении такого теста укажут на it в теле функции, а не на конкретный вызов testSomething в коде.

Правильно

it("does not matter how to define an array", () => testSomething([1, 2, 3], new Array(1, 2, 3))); 

function testSomething(expected_value:SomeValue, actual_value:SomeValue) {
	expect(actual_value).toEquals(expected_value);
}

Независимо от типа Unit-теста, необходимо стремиться к его простоте и читаемости, поэтому не стоит злоупотреблять большим количеством проверяемых утверждений на один тест. В идеале, на один тест должна приходиться проверка одного утверждения. В случаях, когда одной проверкой тест не ограничивается, стоит задуматься как о качестве теста, так и кода, который этот тест тестирует.

by 16.01.2016