Про тесты. Мы-программисты пытаемся писать код, который будет | Экстраполяция IT

Про тесты.

Мы-программисты пытаемся писать код, который будет чистым. Ну, там без дублирования, с всякими инкапсуляциями, наследованиями и переопределениями. Иногда идём на сделку с совестью и немножечко говнокодим, конечно, но каждый раз из-за этого прям сердце сжимается, так сильно нам нравится писать красивый код.

А вот тесты — это прям сплошной антипаттерн. Там сплошное дублирование, и процветает макаронный стиль. Но фишка в том, что так и должно быть.

Давным давно коллега мой придумал шикарное правило в отношении тестов и называл его «правилом Шапокляк». Идея в том, что тесты должны быть, как крокодил Гена — плоскими и зелёными. Чем больше в ваших тестах разного устранения дублирования, наследования, переменных и всяких ленивых вызовов, тем больше тест похож на код, а не на тест.

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

Плохо писать:

user = create(User)
expect(user.full_name).to equal("#{user.first_name} #{user.last_name}")


Это сильно упрощённый пример, но вот expect(2 + 2).to equal(2 + 2) уже отчётливо прослеживается.

Хорошо писать:

user = create(User, first_name: ‘Bob’, last_name: ‘Smith')
expect(user.full_name).to equal("Bob Smith")


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

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