Это второй пост о тестовых атрибутах, которые были описаны в известной теперь статье «
Как тестировать ваши тесты ».
Мы часто забываем, что большинство значений, которые мы получаем от тестов, приходит после того, как мы их написали. Конечно, TDD помогает разрабатывать код, но давайте посмотрим правде в глаза, когда все работает впервые, наши тесты становятся будущими хранителями нашего кода. Оказавшись на месте, мы можем изменить код, надеюсь, к лучшему, зная, что все еще работает.
Но если (и когда) что-то сломается, есть работа, которую нужно сделать. Нам нужно понять, что сработало до того, что сейчас нет. Затем нам нужно проанализировать ситуацию: согласно тому, что мы делаем сейчас, должны ли мы решить эту проблему? Или это новая функциональность, которую мы теперь должны охватить новыми тестами, отбрасывая старую? Наконец, опять кодирование и тестирование, в зависимости от результатов нашего анализа.
Чем больше мы продвигаемся во времени, тесты и код устаревают в нашем разуме. Тогда мы забудем о них полностью. Стоимость изменений возрастает. Этап анализа становится длиннее, потому что нам нужно заново познакомиться с окружающей средой. Нам нужно заново узнать, что еще работает, а что перестало работать. Даже если бы мы знали, мы не помним, какие изменения могут вызвать побочные эффекты и как они сработают.
Эффективные тесты минимизируют этот процесс. Они должны быть читабельными.
Читаемость субъективна. То, что я нахожу читаемым сейчас (сразу после того, как я это написал), через 6 месяцев не будет таким. Не говоря уже о ком-то другом.
Поэтому вместо того, чтобы пытаться определить читаемость теста, давайте разберем его по элементам, которые нас интересуют и могут оценить.
Какое имя
Наиболее важной частью теста (помимо
проверки правильности ) является его имя. Причина проста: когда тест прерывается, имя — это первое, что мы видим, когда тест не пройден. Это первая подсказка, которую мы получаем, что что-то не так, и, следовательно, она должна рассказать нам как можно больше.
Название теста должно включать (как минимум) конкретный сценарий и ожидаемый результат нашего теста. Если мы тестируем API, это должно сказать и об этом.
Например:
@Testpublic void divideCounterBy5Is25() { ...
Я могу понять, что делает тест (сценарий с делением счетчика), детали (деление на 5) и ожидаемый результат для этого сценария (25).
Если это звучит как предложение — даже лучше. Хорошие имена происходят от словесного описания их.
Неважно, используете ли вы заглавные буквы, подчеркивание или что-то другое. Это
является важным , что вы используете один и то же соглашение , что ваша команда согласует.
Имена также должны быть достаточно конкретными, чтобы мысленно отличить их от других тестов с сестрой. Итак, в нашем примере:
@Testpublic void divideCounterBy0Throws() { ...
Этот тест достаточно похож на первое имя, чтобы идентифицировать его как «родственный» сценарий из-за сходства в префиксе. Конкретный сценарий и результат разные. Это важно, потому что, когда эти двое появляются вместе в тестовом средстве, один выходит из строя, а другой нет, это помогает нам найти проблему еще до начала отладки. Это ключи к решению проблемы.
Какое тело
Если наши имена не помогают найти проблему, тестовое тело должно заполнить пробелы. Он должен содержать всю информацию, необходимую для понимания сценариев.
Вот несколько советов, как сделать тестовый код читабельным:
- Тесты должны быть короткими. Около 10-15 строк.
- Если настройка длинная, распакуйте ее в функции с описательными именами.
- Избегайте использования функций предварительного тестирования, таких как @Before или MSTest JUnit [TestInitialize]. Вместо этого используйте методы, вызываемые непосредственно из теста. Когда вы смотрите на код, настройки и демонтаж должны быть видны, в противном случае вам придется искать дальше и предполагать даже больше. Отладка тестов с помощью методов настройки также неинтересна, потому что вы вводите тест в определенном контексте, который может вас удивить.
- Избегайте использования базовых тестовых классов. Они также скрывают информацию, актуальную для понимания сценариев. Предпочтение композиции перед наследованием работает и здесь.
- Выделите часть утверждения.
- Убедитесь, что тело и имя совпадают.
Анализ требует времени, а самый худший (и самый медленный) требует отладки. Тесты (и код) должны быть достаточно читабельными, чтобы помочь нам обойти этот
расточительный процесс .
Лучшая читаемость в считанные минуты
Мы предвзяты и поэтому думаем, что мы пишем код и тесты, которые так хороши, что каждый может это понять. Мы часто ошибаемся.
В Agile обратная связь является ответом.
Используйте «Закон Третьего Уха». Возьмите ухо ничего не подозревающего коллеги и поднесите его ближе к экрану, и она скажет вам, понимает ли она, что делает тест.
Еще лучше, пара во время написания тестов. Обратная связь приходит нам по продуктам, и вы получаете лучшие тесты.
Что бы вы ни делали, не оставляйте это на потом. И не используйте насилие, если вам не нужно.
Сделайте тесты читабельными сейчас, чтобы вы могли прочитать их позже.