День 1350. #Testing Не Полагайтесь на Порядок Юнит-Тестов Одна из распространённых ловушек, в которую может попасть новичок при написании юнит-тестов, — это положиться на их последовательное выполнение. Это ведь имеет смысл. В тестах можно ли создавать, читать и удалять некоторые данные, почему бы не использовать данные из прошлого теста? Недостатки 1. Вы должны поддерживать состояние, и это очень плохо Цель юнит-теста — подтвердить, что определённая часть кода выполняет свою работу правильно. Чтобы в этом убедиться, эту конкретную часть надо изолировать от всего остального. Поэтому, если мы полагаемся на то, что другой тест подготовит данные для нас, мы не следуем этому принципу. Кроме того, очень сложно отслеживать входящие данные теста, если они не очевидны с первого взгляда. Представьте, что вы присоединяетесь к новой команде и должны выяснить, где генерируются данные для теста. Ужас! 2. Один новый тест может сломать все тесты Что если нам надо добавить новый тест? Если в какой-то момент в тестах нам нужно иметь определённые данные, как мы можем быть уверены, что новый тест их не испортит? А что, если нужно удалить тест, который больше не нужен? 3. Невозможно использовать тест-кейсы Это функциональность, которая позволяет вам запускать один и тот же тест несколько раз с разными параметрами. Поэтому, если вам нужно, чтобы ваш тест был подготовлен другим тестом, эта функция, вероятно, не будет совместима с вашими тестами. 4. Увеличивается время отладки Если юнит-тест падает, мы не сможем сразу же запустить его снова, так как нужно будет запустить все остальные тесты перед ним, чтобы потом его можно было отладить. Если проблему трудно найти, может потребоваться много запусков. А возможно, проблема даже не в этом тесте, она может быть связана с каким-то другим тестом, который неправильно выполнил свою часть. Как не полагаться на порядок юнит-тестов В шаблоне Arrange Act Assert (AAA), все данные, необходимые для теста, должны быть подготовлены на этапе Arrange. Некоторые системы тестирования предлагают методы настройки (SetUp). Можно использовать отдельные вспомогательные методы, поскольку это помогает избежать хранения состояния и улучшает читаемость. Если вы сохраняете данные, проверьте, возможно, вам это и не нужно. Рассмотрите возможность использования моков, чтобы вместо проверки, например, были ли ваши данные записаны на диск, вы могли бы просто проверить, был ли вызван метод Write() фиктивного класса. Но если избежать сохранения данных не удаётся, нужно очищать их в конце теста. Не стесняйтесь использовать вспомогательные функции системы тестирования, такие как TearDown. Итого Необходимость в конкретном порядке исполнения юнит-тестов — это код с душком. Есть лучшие способы убедиться, что данные находятся в желаемом состоянии, а также очистить эти данные перед запуском следующих тестов. Тем самым мы улучшаем жизнь себе будущему и нашим коллегам, а также повышаем нашу продуктивность. Источник: https://intodot.net/unit-testing-best-practices-avoid-relying-on-test-order/