Не пишите условную логику в тестах

Оригинальная статья

Условная логика не должна использоваться в тестах

Это одно из самых важных правил при
написании хороших тестов.

Вы должны с подозрением относиться к любым тестам, которые включают конструкции типа

На это есть две основные причины

1. Это заставляет вас читать код.

Я не должен читать код, чтобы узнать, почему тест не сработал.

import {expect} from 'vitest';
...
test('JacketAdvisor', () => {
    ...
    if (weatherOutside === 'cold') {
        expect(sut.shouldBringAJacket()).toBeTruthy()
    } else {
        expect(sut.shouldBringAJacket()).toBeFalsy()
    }
}) 

Приведенный выше код достаточно прост для чтения, но если тест не пройдет, я получу следующее
сообщение

FAIL  path/to/tests > JacketAdvisor
AssertionError: expected true to be falsy

и мне придется открыть код, чтобы выяснить причину неудачи.
Каждый случай должен быть обработан в отдельном тесте

import {describe, expect} from 'vitest';

...

describe('JacketAdvisor', () => { 
    test('with cold weather shouldBringAJacket returns true', () => {
        ...
        expect(sut.shouldBringAJacket()).toBeTruthy()
    })

    test('without cold weather shouldBringAJacket returns false', () => {
        ...
        expect(sut.shouldBringAJacket()).toBeFalsy()
    })
})

Таким образом, когда тест не сработает, у меня будет что-то вроде этого:

FAIL  path/to/tests > JacketAdvisor > with cold weather shouldBringAJacket returns true
AssertionError: expected true to be falsy

И я сразу пойму, почему тест не удался.

2. Внедряется непроверенный код

Это, возможно, более коварная проблема. Если у вас есть непроверенная логика, которую вы используете
для тестирования вашего кода, у вас нет тестов, которые подтверждают, что вы действительно делаете
правильные утверждения.

Например, если я случайно установлю weatherOutside в 'col' во втором примере.
выше, первый тест будет провален. Но во втором примере этот код expect(sut.shouldBringAJacket()).toBeTruthy()
просто никогда не выполнится. Я не узнаю, что код был неправильным, пока он не попадет в продакшн.
потому что тестовый код был неправильным и содержал ошибку.

Но мне нужна условная логика для некоторого утверждения.

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

1. Вы работаете с устаревшим кодом

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

Просто помните, что это временно. Когда вы рефакторите систему до такой степени.
когда ее компоненты можно будет тестировать изолированно, протестируйте эти компоненты и
удалите старые тесты.

2. Вы пишете библиотеку тестирования или пользовательское утверждение.

На самом деле невозможно иметь тест без условной логики.
потому что под капотом все утверждения выглядят примерно так:

function assertTruthy(val) {
    if (val == false) {
        throw new AssertionError({message: 'expected true to be false'});
    }
}

Вместо «Не пишите условную логику в тестах» правило, вероятно, должно быть следующим
«Тестовый код никогда не должен иметь логику, которая разветвляется дальше одного уровня, и должен только
ветвиться только для того, чтобы сделать утверждение» (конечно, это не очень удачное название).

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

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

Это все же исключения, к условной логике все равно следует относиться как к запаху,
не стоит писать кучу пользовательских утверждений, чтобы обойти это правило.