День 1190. #Testing Тестировать Сначала или Потом Когда писать тесты: до написания кода или после. Сначала код Это обычный подход, а также самый интуитивно понятный способ написания тестов. Сначала пишете код, а затем покрываете его тестами. Ничего сложного: это «нормальный» способ разработки ПО. Сначала тесты Противоположный подход: сначала вы пишете тест для функциональности, которую собираетесь разработать, а затем саму функциональность. Это наиболее важное отличие разработки через тестирование (TDD) от традиционного подхода. Процесс TDD 1. Напишите тест Так вы описываете требования к функциональности, которую скоро разработаете, и формулируете их в виде утверждений в тесте. 2. Убедитесь, что тест завершается неудачей по уважительной причине  Тест должен завершиться неудачей из-за проблем с тестируемой функциональностью, а не из-за какой-то несвязанной проблемы, типа исключения уровня приложения. 3. Сделайте так, чтобы тест прошёл Реализуйте реальную функциональность, покрываемую тестом. Здесь качество кода не важно; цель в том, чтобы тест стал зеленым. 4. Рефакторинг Если нужно, почистите код. Причина отделения этого шага в том, что легче рефакторить существующий беспорядочный код, чем писать чистый код с самого начала. Преимущества TDD Тесты проверяют код приложения, но кто проверяет тесты? Как убедиться, что тесты проверяют функциональность, а не просто бездействуют? Эту проблему решает TDD. Увидев, что тест проваливается из-за отсутствия функциональности (или из-за неправильной реализации), вы подтверждаете его правильность. Вы знаете, что, если код приложения перестанет работать должным образом, тест укажет на это. Эта практика снижает вероятность ложноотрицательных результатов (ложных зелёных тестов): вы уже видели, как тест провалился, и можете ожидать, что он сделает это снова. Поэтому шаг 2 так важен. Если тест терпит неудачу по несвязанной причине (например, неправильной настройке), вы не проверите этот тест и не можете знать, сработает ли он, если функциональность сломается. При подходе «сначала код» эту проверку необходимо выполнять вручную: изменить код, чтобы сымитировать ошибку, убедиться, что тест падает, и изменить код обратно. Это утомительно, и многие пропускают этот шаг, что может привести к некорректным тестам. В TDD этот шаг встроен в сам процесс написания кода, т.е. не нужно выполнять какую-либо дополнительную работу. Преимущества «тестов после» Гибкость. Т.к. вам не нужно беспокоиться о тестах, вы можете легко менять код приложения: провести рефакторинг или даже полностью перепроектировать его. С тестами сделать это сложнее, потому что придётся исправлять тесты после каждого редизайна. Когда использовать Оба подхода нужно применять на нужном этапе вашего проекта. Можно выделить 2 этапа: 1. Делаем что надо 2. Делаем как надо Сначала нужно наметить масштаб проекта, чтобы убедиться, что это правильное решение, и только потом создавать это решение. Первый этап включает эксперименты, наброски модели предметной области, рисование на доске и т. д. На этом этапе не нужны тесты: они будут только задерживать, и есть большая вероятность, что их придётся выбросить вместе с экспериментальным кодом. Как только вы уверены, что делаете что надо, можно перейти к этапу 2. Здесь вы можете следовать TDD и получать все долгосрочные преимущества, такие как хорошее тестовое покрытие и качественные тесты. Проблема с TDD заключается в том, что для того, чтобы быть продуктивным, вам нужно точно знать, что вы создаёте. Однако, как только вы это узнаете, вы сможете извлечь большую пользу из подхода «сначала тесты». Еще одна область, где TDD полезен — исправление ошибок. Если вы нашли ошибку, не исправляйте ее сразу. Сначала напишите тест для воспроизведения этой ошибки, убедитесь, что он падает, а затем исправьте код. Таким образом, вам больше никогда не придется беспокоиться об этой ошибке. Источник: khorikov.org/posts/2…proaches