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

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

10 <p>Перейдем к условным конструкциям:</p>

11 <p>Фактически, любое ветвление внутри тестов - это несколько тестов в рамках одного теста. Надо от этого избавляться и никогда так не писать.</p>

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

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

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

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

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

17 <p>Чаще всего, единственным результатом такого разделения будет слишком большой объем кода и сложный рефакторинг в будущем, когда кода станет по-настоящему много.</p>

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

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

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

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

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

23 <li>Тесты позволяют реже проверять код вручную, что ускоряет рефакторинг</li>

24 <li>Тесты снижают уровень стресса</li>

25 </ul>