Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>Как и любой другой код, тесты можно писать по-разному - в том числе очень плохо. Помимо каких-то общих практик и стандартов кодирования у тестов есть свои особенности, о которых надо знать. В этом уроке мы пройдемся по некоторым из них.</p>

2 <h2>Взаимное влияние тестов</h2>

3 <p>Одно из ключевых правил - тесты не должны влиять друг на друга. Это значит, что любой тест выполняется так, как будто других тестов не существует в природе.</p>

4 <p>Нарушить это правило очень просто. Один тест может создать файл, изменить переменную или записать что-то в базу. Если остальные тесты наткнутся на эти изменения, то они могут работать неверно, например:</p>

5 <ul><li>Упасть там, где не должны падать</li>

6 <li>Успешно пройти там, где не должны проходить</li>

7 </ul><p>Кроме этого, в такой ситуации вводится неопределенность. Такие тесты могут падать без видимых причин. Например, когда тест запускают изолированно, он работает, а когда вместе с остальными - падает:</p>

8 <p>Особенно часто такая ситуация возникает в тестах, активно взаимодействующих с внешней средой: базой данных или файловой системой. Тестирование побочных эффектов имеет свои хитрости, которые мы рассматриваем в курсе по продвинутому тестированию.</p>

9 <h2>Условные конструкции в тесте</h2>

10 <p>Любое ветвление в тестах - это фактически несколько тестов в одном. Ветвления порождают код, который сам нуждается в тестировании. Так происходит, потому что порядок выполнения становится не очевидным - его можно случайно нарушить. Лучше создать независимые тесты для каждой ветки.</p>

11 <h2>Тест вне тестов</h2>

12 <p>Задача фикстур - готовить данные и среду для тестирования, а задача тестовых функций - проводить проверки и вызывать код для тестирования. Но иногда разработчики переусердствуют:</p>

13 <p>В этом примере тестируемый код вызывается в функции result(). Такой подход усложняет анализ тестов, потому что переворачивает все с ног на голову.</p>

14 <h2>Слишком сильная детализация</h2>

15 <p>Некоторые программисты стремятся максимально разносить код по файлам, модулям и функциям. То же самое наблюдается и в тестах. Вместо одного теста со всеми необходимыми проверками, они создают пять тестов, в каждом из которых ровно одна проверка:</p>

16 <p>У такого разделения есть одно последствие - кода станет больше, а значит сложнее будет провести рефакторинг в будущем.</p>

17 <h2>Код с тестами писать дольше, чем код без тестов?</h2>

18 <p>Это очень интересный вопрос, по которому можно понять, насколько хорошо программист умеет писать тесты.</p>

19 <p>Некоторые виды тестирования действительно сложны и требуют дополнительного времени. Но при этом ежедневные тесты, которые пишутся вместе с кодом, должны приводить к ускорению разработки. И на это есть свои причины:</p>

20 <ul><li>Тесты помогают раньше выявить неудачные решения и поэтому влияют на дизайн кода</li>

21 <li>Тесты упрощают подготовку входных данных - ее нужно сделать всего один раз</li>

22 <li>Тесты упрощают проверку результата работы кода, ведь сами проверяют все, в том числе и пограничные случаи</li>

23 <li>Регулярные тесты упрощают и ускоряют рефакторинг, потому что с ними не приходится проверять части кода вручную</li>

24 <li>Тесты улучшают атмосферу в команде, потому что снижают уровень стресса</li>

25 </ul>