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