День девятьсот двадцать третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
94. Пишите тесты для людей
Вы пишете тесты для части или для всего вашего кода? Поздравляю! Вы пишете тесты перед написанием кода? Ещё лучше! Это делает вас одним из первых, кто встал на передовые позиции в области разработки программного обеспечения. Но хорошие ли вы пишете тесты? Как вы можете их оценить? Один из способов - спросить: «Для кого я пишу тесты?» Если ответ - «Для себя, чтобы избавить себя от усилий по исправлению ошибок» или «Для компилятора, чтобы убедиться, что они проходят», то велика вероятность, что вы пишете не самые лучшие тесты. Так для кого же вы должны писать тесты? Для человека, пытающегося понять ваш код.

Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код. Для каждого сценария использования тест(ы):
1. Описывают контекст, отправную точку или предварительные условия, которые должны быть выполнены.
2. Иллюстрируют, как запускается программное обеспечение.
3. Описывают ожидаемые результаты или постусловия, которые необходимо проверить.

В разных сценариях использования эти три пункта будут немного различаться. Человек, пытающийся понять ваш код, должен иметь возможность взглянуть на несколько тестов и, сравнив эти три части в рассматриваемых тестах, понять, что заставляет программное обеспечение вести себя по-разному. Каждый тест должен чётко иллюстрировать причинно-следственную связь между этими тремя частями.

Это означает, что то, что не видно в тесте, так же важно, как и то, что видно. Слишком много кода в тесте отвлекает читателя несущественными мелочами. По возможности скрывайте такие мелочи за осмысленными вызовами методов - рефакторинг Extract Method - ваш лучший друг. И убедитесь, что вы дали каждому тесту осмысленное имя, которое описывает конкретный сценарий использования, чтобы читателю тестов не приходилось копаться в коде, чтобы понять, каковы могут быть различные варианты. Имена тестового класса и его методов должны включать по крайней мере название тестируемой начальной точки и сценарий использования. Это позволяет проверить покрытие тестами, просто быстро прочитав имена методов. Также может быть полезно включить ожидаемые результаты в названия тестовых методов, если это не сделает их слишком длинными.

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Gerard Meszaros