Я ввел модульные тесты для кодовых баз, в которых его раньше не было. В последнем большом проекте, в котором я участвовал, когда я пришел в команду, продукт уже находился в производстве с нулевыми юнит-тестами. Когда я ушел - 2 года спустя - у нас было около 4500 или около того тестов, дающих около 33% покрытия кода в кодовой базе с 230000 + производственным LOC (финансовое приложение Win-Forms в реальном времени). Это может показаться незначительным, но результатом стало значительное улучшение качества кода и количества дефектов, а также повышение морального духа и прибыльности.
Это можно сделать, если у вас есть как точное понимание, так и приверженность заинтересованных сторон.
Прежде всего, важно понимать, что модульное тестирование - это навык сам по себе. Вы можете быть очень продуктивным программистом по «общепринятым» стандартам и при этом испытывать трудности при написании модульных тестов, которые можно масштабировать в рамках более крупного проекта.
Кроме того, особенно для вашей ситуации, добавление модульных тестов к существующей базе кода, не имеющей тестов, также является специализированным навыком само по себе. Если вы или кто-то из вашей команды не имеет успешного опыта внедрения модульных тестов в существующую кодовую базу, я бы сказал, что чтение книги Фезера является обязательным (не обязательно или настоятельно рекомендуется).
Переход к модульному тестированию кода - это вложение в людей и навыки, равно как и в качество кодовой базы. Понимание этого очень важно с точки зрения мышления и управления ожиданиями.
Теперь для ваших комментариев и вопросов:
Однако я обеспокоен тем, что в конечном итоге я упущу из виду общую картину и в конечном итоге пропущу фундаментальные тесты, которые были бы включены, если бы я использовал TDD с самого начала.
Краткий ответ: да, вы пропустите тесты, и да, они могут изначально не выглядеть так, как если бы они были в ситуации «зеленого поля».
Ответ на более глубоком уровне таков: это не имеет значения. Вы начинаете без тестов. Начните добавлять тесты и по ходу рефакторинга. По мере повышения уровня навыков начните поднимать планку для всего нового написанного кода, добавляемого в ваш проект. Продолжайте совершенствоваться и т. Д.
Теперь, читая здесь между строк, у меня складывается впечатление, что это исходит из мышления «совершенство как оправдание бездействия». Лучшее мышление - сосредоточиться на доверии к себе. Так как вы, возможно, еще не знаете, как это сделать, вы поймете, как это сделать, и заполните пробелы. Поэтому волноваться не о чем.
Опять же, это умение. Вы не можете линейно перейти от нулевых тестов к TDD-совершенству за один «процесс» или «пошаговый» подход. Это будет процесс. Ваши ожидания должны заключаться в постепенном и постепенном прогрессе и улучшении. Нет волшебной пилюли.
Хорошая новость заключается в том, что по прошествии месяцев (и даже лет) ваш код постепенно начнет становиться «правильным», хорошо продуманным и хорошо протестированным кодом.
В качестве примечания. Вы обнаружите, что основным препятствием для внедрения модульных тестов в старую кодовую базу является отсутствие согласованности и чрезмерные зависимости. Таким образом, вы, вероятно, обнаружите, что наиболее важным навыком станет устранение существующих зависимостей и разделение кода, а не написание самих модульных тестов.
Существуют ли какие-либо процессы / шаги, которых следует придерживаться, чтобы гарантировать, что существующие решения правильно протестированы, а не просто внедрены?
Если он у вас еще не установлен, настройте сервер сборки и настройте сборку с непрерывной интеграцией, которая запускается при каждой проверке, включая все модульные тесты с покрытием кода.
Обучайте своих людей.
Начните с чего-нибудь и начните добавлять тесты, пока вы продвигаетесь с точки зрения клиента (см. Ниже).
Используйте покрытие кода в качестве ориентира для определения того, какая часть вашей производственной базы кода проходит тестирование.
Время сборки всегда должно быть БЫСТРЫМ. Если ваше время сборки медленное, ваши навыки модульного тестирования отстают. Найдите медленные тесты и улучшите их (разделите производственный код и тестируйте изолированно). Хорошо написано, вы легко сможете провести несколько тысяч модульных тестов и при этом завершить сборку менее чем за 10 минут (~ 1-несколько мс / тест - хороший, но очень грубый ориентир, некоторые исключения могут применяться, например, код с использованием отражения и т. Д. ).
Осмотрите и адаптируйте.
Как я могу гарантировать, что тесты хорошего качества, а не просто случай любого теста, лучше, чем отсутствие тестов.
Ваше собственное суждение должно быть вашим основным источником реальности. Нет метрики, которая могла бы заменить навык.
Если у вас нет такого опыта или суждения, подумайте о том, чтобы заключить контракт с кем-нибудь, кто знает.
Два приблизительных вторичных показателя - это общее покрытие кода и скорость сборки.
Стоит ли прилагать усилия к существующему решению, которое находится в производстве?
Да. Подавляющая часть денег, потраченных на систему или решение, созданное на заказ, тратится после того, как они запущены в производство. А инвестирование в качество, людей и навыки никогда не должно выходить из моды.
Не лучше ли игнорировать тестирование этого проекта и добавить его в возможной будущей переписывании?
Вам нужно будет принять во внимание не только инвестиции в людей и навыки, но, что наиболее важно, общую стоимость владения и ожидаемый срок службы системы.
Мой личный ответ был бы «да, конечно» в большинстве случаев, потому что я знаю это намного лучше, но я понимаю, что могут быть исключения.
Что будет полезнее; потратить несколько недель на добавление тестов или несколько недель на добавление функций?
Ни то, ни другое. Ваш подход должен заключаться в добавлении тестов в вашу базу кода, ПОКА вы делаете прогресс с точки зрения функциональности.
Опять же, это вложение в людей, навыки И качество кодовой базы, и поэтому потребуется время. Члены команды должны научиться устранять зависимости, писать модульные тесты, изучать новые привычки, улучшать дисциплину и понимание качества, как лучше разрабатывать программное обеспечение и т. Д. Важно понимать, что когда вы начинаете добавлять тесты, члены вашей команды, скорее всего, этого не сделают. обладать этими навыками еще на том уровне, который необходим для успеха такого подхода, поэтому остановить прогресс, чтобы тратить все время на добавление множества тестов, просто не сработает.
Кроме того, добавление модульных тестов к существующей кодовой базе любого значительного размера проекта - это КРУПНАЯ задача, требующая приверженности и настойчивости. Вы не можете изменить что-то фундаментальное, ожидайте многого по пути и попросите своего спонсора не ожидать какой-либо рентабельности инвестиций, останавливая поток бизнес-ценности. Это не сработает, и, честно говоря, не должно.
В-третьих, вы хотите привить своей команде разумные ценности, ориентированные на бизнес. Качество никогда не достигается за счет клиента, и вы не можете действовать быстро без качества. Кроме того, клиент живет в меняющемся мире, и ваша задача - помочь ему адаптироваться. Согласованность с клиентами требует как качества, так и потока ценности для бизнеса.
Вы выплачиваете технический долг. И вы делаете это, продолжая обслуживать постоянно меняющихся потребностей своих клиентов. Постепенно по мере выплаты долга ситуация улучшается, и становится легче обслуживать клиентов и приносить больше пользы. И т.д. Этот позитивный импульс - то, к чему вы должны стремиться, потому что он подчеркивает принципы устойчивого темпа и будет поддерживать и улучшать мораль - как для вашей команды разработчиков, так и для ваших клиентов и ваших заинтересованных сторон.
надеюсь, это поможет