Хотя я полностью сторонник модульного тестирования, я иногда задаюсь вопросом, действительно ли эта форма первой разработки теста действительно полезна ...
Такие небольшие, тривиальные тесты могут стать «канарейкой в угольной шахте» для вашей кодовой базы, предупреждая об опасности, пока не стало слишком поздно. Тривиальные тесты полезно держать под рукой, потому что они помогают вам правильно взаимодействовать.
Например, подумайте о тривиальном тесте, который проводится для проверки того, как использовать API, с которым вы не знакомы. Если этот тест имеет какое-либо отношение к тому, что вы делаете в коде, который использует API «по-настоящему», полезно сохранить этот тест. Когда API выпускает новую версию, и вам нужно выполнить обновление. Теперь у вас есть свои предположения о том, как вы ожидаете, что API будет вести себя, записанные в исполняемом формате, который вы можете использовать для выявления регрессий.
... [I] В реальном процессе, у вас есть 3-4 уровня над кодом (бизнес-запрос, документ с требованиями, документ архитектуры), где фактически определенное бизнес-правило (цена скидки - это цена - скидка) может быть неправильно определено. В таком случае ваш модульный тест ничего не значит для вас.
Если вы годами программировали без написания тестов, возможно, вам не сразу станет очевидным, что в этом есть какая-то ценность. Но если вы считаете, что лучший способ работы - это «выпускать раньше, выпускать часто» или «гибкость» в том смысле, что вам нужна возможность быстрого / непрерывного развертывания, то ваш тест определенно что-то значит. Единственный способ сделать это - узаконить каждое изменение, которое вы вносите в код, с помощью теста. Независимо от того, насколько небольшой тест, если у вас есть зеленый набор тестов, вы теоретически можете его развернуть. См. Также «непрерывное производство» и «бессрочное бета-тестирование».
Вам также не обязательно проходить тестирование, чтобы иметь такой образ мышления, но, как правило, это наиболее эффективный способ достичь желаемого. Когда вы выполняете TDD, вы замыкаетесь в небольшом двух-трехминутном цикле Red Green Refactor. Ни в коем случае вы не можете остановиться и уйти, и в ваших руках будет полный беспорядок, на отладку и сборку которого уйдет час.
Кроме того, ваш модульный тест - еще одна точка отказа ...
Успешный тест - это тест, демонстрирующий сбой в системе. Неудачный тест предупредит вас об ошибке в логике теста или в логике вашей системы. Цель ваших тестов - взломать ваш код или доказать, что один сценарий работает.
Если вы пишете тесты после кода, вы рискуете написать «плохой» тест, потому что для того, чтобы убедиться, что ваш тест действительно работает, вам нужно увидеть, что он сломан и работает. Когда вы пишете тесты после кода, это означает, что вам нужно «вскрыть ловушку» и ввести ошибку в код, чтобы увидеть, что тест не прошел. Большинство разработчиков не только обеспокоены этим, но и утверждают, что это пустая трата времени.
Что мы здесь получаем?
В таком поступке определенно есть преимущества. Майкл Фезерс определяет «устаревший код» как «непроверенный код». Применяя этот подход, вы узакониваете каждое изменение, которое вносите в свою кодовую базу. Это более строго, чем отсутствие тестов, но когда дело доходит до поддержки большой базы кода, это окупается.
Говоря о Feathers, есть два замечательных ресурса, которые вы должны изучить по этому поводу:
Оба они объясняют, как использовать эти типы практик и дисциплин в проектах, которые не являются «гринфилдом». Они предоставляют методы написания тестов для тесно связанных компонентов, жестко привязанных зависимостей и вещей, над которыми вы не обязательно можете контролировать. Все дело в поиске "швов" и их проверке.
[I] Если цена со скидкой неверна, команда тестирования все равно найдет проблему, как модульное тестирование сохранило работу?
Подобные привычки похожи на вложение. Возврат не происходит немедленно; они накапливаются со временем. Альтернатива отсутствию тестирования - это, по сути, взять на себя ответственность за невозможность уловить регрессии, ввести код, не опасаясь ошибок интеграции, или принять дизайнерские решения. Прелесть в том, что вы узакониваете каждое изменение, внесенное в вашу кодовую базу.
Что мне здесь не хватает? Пожалуйста, научите меня любить TDD, так как я пока не могу принять его как полезный. Я тоже хочу, потому что хочу оставаться прогрессивным, но для меня это просто не имеет смысла.
Я смотрю на это как на профессиональную ответственность. Это идеал, к которому нужно стремиться. Но это очень сложно и утомительно. Если вам это небезразлично и вы чувствуете, что не должны создавать непроверенный код, вы сможете найти в себе силы и научиться хорошим привычкам тестирования. Одна вещь, которую я сейчас много делаю (как и другие), - это ограничиваю себя часом, чтобы написать код вообще без каких-либо тестов, а затем иметь дисциплину, чтобы выбросить его. Это может показаться расточительным, но на самом деле это не так. Не то чтобы это упражнение стоило компании материальных средств. Это помогло мне понять проблему и понять, как писать код таким образом, чтобы он был более качественным и тестируемым.
В конечном итоге я бы посоветовал вам, если у вас действительно нет желания преуспевать в этом, не делайте этого вообще. Плохие тесты, которые не обслуживаются, плохо работают и т. Д., Могут быть хуже, чем отсутствие тестов. Трудно научиться самостоятельно, и вам, вероятно, это не понравится, но будет практически невозможно научиться, если у вас нет желания делать это или вы не видите в этом достаточно ценности, чтобы оправдывают затраты времени.
Пара людей постоянно упоминает, что тестирование помогает обеспечить соблюдение спецификации. По моему опыту, спецификации тоже чаще всего были неправильными ...
Клавиатура разработчика - это место, где резина встречается с дорогой. Если спецификация неверна, и вы не поднимаете этот флаг, то весьма вероятно, что вас обвинят в этом. Или, по крайней мере, ваш код будет. Трудно придерживаться дисциплины и строгости при тестировании. Это совсем не просто. Это требует практики, много обучения и много ошибок. Но в конце концов это окупается. В быстро развивающемся, быстро меняющемся проекте это единственный способ спать по ночам, даже если это замедляет вас.
Еще одна вещь, о которой следует подумать, заключается в том, что методы, которые в основном аналогичны тестированию, доказали свою эффективность в прошлом: «чистая комната» и «проектирование по контракту» имеют тенденцию создавать одни и те же типы конструкций «метакода», которые тесты делают, и применяют их в разных точках. Ни один из этих методов не является серебряной пулей, и строгость в конечном итоге обойдется вам в объеме функций, которые вы можете предоставить с точки зрения времени выхода на рынок. Но дело не в этом. Речь идет о возможности поддерживать то, что вы делаете. И это очень важно для большинства проектов.