День 1113. #UnitTesting
Вы Неправильно Называете Тесты! Начало
Важно давать тестам выразительные имена. Правильное наименование помогает понять, что проверяет тест и как ведёт себя система.
Существует множество соглашений именования тестов. Одним из наиболее известных и, вероятно, одним из наименее полезных является:
[MethodUnderTest]_[Scenario]_[ExpectedResult]
Здесь
- MethodUnderTest – имя тестируемого метода,
- Scenario – условия проведения теста,
- ExpectedResult – ожидаемый в этих условиях результат.
Это бесполезно, потому что побуждает вас сосредоточиться на деталях реализации, а не на поведении. Наоборот, простые фразы справляются со своей задачей гораздо лучше: они более выразительны и не загоняют вас в жесткую структуру именования. Простыми фразами вы можете описать поведение системы так, чтобы это было понятно клиенту или эксперту в предметной области.
Можно возразить, что на самом деле не имеет значения, что подумает об имени непрограммист. В конце концов, модульные тесты пишутся программистами для программистов, а не для экспертов в предметной области.
Это верно, но только до определенной степени. Загадочные имена налагают когнитивный налог на всех. Требуются дополнительные мозговые усилия, чтобы выяснить, что именно проверяется тестом и как это соотносится с бизнес-требованиями. Может показаться, что разобрать имя не так уж и сложно, но нагрузка со временем увеличивается. Это медленно, но верно, увеличивает стоимость обслуживания всего набора тестов. Особенно это заметно, если вы возвращаетесь к тесту после того, как забыли о специфике фичи, или пытаетесь понять тест, написанный коллегой. Читать чужой код уже достаточно сложно. Любая помощь в его понимании очень полезна.
Первоначальное имя, написанное простым языком, читается гораздо проще. Это простое описание тестируемого поведения.
Рекомендации по именованию модульных тестов:
1. Не вводите жёсткую политику именования. Вы просто не сможете втиснуть высокоуровневое описание сложного поведения в узкие рамки такой политики. Разрешите свободу самовыражения.
2. Назовите тест так, как если бы вы описывали сценарий непрограммисту, знакомому с предметной областью.
3. Разделяйте слова символами подчеркивания. Это помогает улучшить читаемость, особенно длинных имен.
Использование символов подчёркивания не касается имён тестовых классов, они обычно не такие длинные. Также обратите внимание, что хотя часто используется шаблон [ClassName]Tests при именовании тестовых классов, это не означает, что тесты ограничены проверкой только этого ClassName. Модуль в модульном тестировании — это модуль поведения, а не класс. Эта единица может охватывать один или несколько классов, фактический размер не имеет значения. Тем не менее, нужно откуда-то начинать. Рассматривайте класс в [ClassName]Tests просто как точку входа, API, с помощью которого вы можете проверить единицу поведения.
Продолжение следует…
Источник: enterprisecraftsmanship.com/posts/y…ts-wrong
