Получить мяч катится по TDD

Я являюсь частью команды разработчиков, которая работает со многими другими командами, чтобы поддерживать и улучшать приложение, которое использовалось не менее 15 лет. Когда это было впервые построено и спроектировано, TDD было неслыханно.

Приложение достаточно стабильное, и мы редко сталкиваемся с ошибками, вызывающими остановку шоу, но в среднем мы делаем примерно одну или две ошибки в неделю, которые серьезно снижают качество обслуживания. Эти ошибки занимают много времени, чтобы найти и исправить, в основном из-за указывания пальцем, и единственное тестирование, которое у нас есть, это тестирование интерфейса. Поскольку до того, как устранить ошибку, нужно потратить много времени, и я, и другой разработчик планируем предложить разработку через тестирование. Скоро будет новый пересмотр, и мы хотели бы видеть, что почти завершено модульное тестирование на новых модулях, мы также планируем предложить создание тестовых модулей для любого кода, который мы должны изменить, что является унаследованным (то есть исправление ошибки или реализация функции ), но не тратить время на разработку тестовых случаев для кода, который не вызвал проблем.

Мне это кажется разумным. В этом месяце у нас была ошибка, исправление которой заняло более двух недель, но ее можно было обнаружить до развертывания, если бы было выполнено модульное тестирование. Но нашим менеджерам просто кажется, что они собираются потратить больше денег.

Как мне убедить наших клиентов, что они хотят потратить деньги на модульное тестирование и разработку через тестирование? Есть ли какие-либо исследования, которые показывают окупаемость модульного тестирования?

Непосредственное включение полномасштабного TDD в устаревший код, проект сопровождения является очень трудным делом. Подход, который я видел, очень хорошо работает, заключается в следующем. Для каждой обнаруженной ошибки создайте автоматический неединичный тест, демонстрирующий эту ошибку. Под «неединичным» я подразумеваю то, что может касаться многих частей системы, поражать базу данных и файловую систему и т. Д., Но под «автоматизированным» я подразумеваю работу без вмешательства человека. Это тот тип теста, который вам понадобится в вашем наборе регрессии в любом случае. Его написание выполняет много вещей: оно делает вас тестируемым, даже на этом очень грубом уровне, и предоставляет вам совокупность кода, который может иметь какое-то отношение к ошибке, поэтому он обучает и информирует вас о очень конкретно релевантный материал.

Но это еще не конец. После того, как этот тест запущен и работает красным (демонстрирует ошибку в коде), найдите время, чтобы выяснить, что не так (вы должны сделать это, в любом случае). Но пока не чини. Как только вы изолировали, что вы думаете, это проблема - напишите блоктест, который демонстрирует эту проблему. Теперь у вас есть кое-что, с чем вы можете работать (и не случайно вам, возможно, пришлось немного реорганизовать его в сторону еще большей тестируемости). Исправьте ошибку. Смотрите прохождение модульного теста. Возможно, дополнить это некоторыми крайними случаями; получите эту единицу - ту, которая стоит всего две недели времени - прочную, чистую и хорошо проверенную. Теперь запустите регрессионный тест и посмотрите, как он прошел (конечно, если он этого не сделает, у вас есть еще какие-то исследования и работа на уровне подразделений - повторяйте, пока он тоже не пройдет). Проверьте все это. Что у вас есть? Регрессионные тесты для ранее неудачного кода. Модульные тесты для ранее неудачного кода. Рабочий код, который не работает. Код лучше разработан, потому что теперь он более тестируем, чем был. Лучшая уверенность в вашей кодовой базе,

Это не "чистый" TDD. Но он быстро показывает результаты и со временем улучшает качество вашего кода. Результаты помогут вам получить управленческий взнос.

В моей компании я просто использовал метод «только грубиян» от JoelOnSoftware и начал писать модульные тесты всякий раз, когда я обычно просто собирал какое-то одноразовое консольное приложение. Я начал делать вещи намного быстрее с более стабильными выпусками, и меня заметили. Когда меня спросили, что я делаю, я объяснил, что начал использовать TDD и писать модульные тесты всякий раз, когда модифицировал старый код или написал новый. Мои коллеги-разработчики начали проявлять любопытство и сами начали использовать интегрированные модульные тесты. Я не думаю, что есть хороший аргумент для написания тестов для работающего унаследованного кода, но если вы сможете доказать, что написание автоматических тестов быстрее и удобнее, чем написание спагетти для взлома консоли, то умные разработчики последуют этому примеру.Другие преимущества, которые приводят к более высокому качеству программного обеспечения, также будут там, но ключ к тому, чтобы заставить разработчика подписаться, показывает, что это облегчает их жизнь. Что касается подписания бизнесом, того факта, что это приведет к созданию более качественного программного обеспечения и, вероятно, потребуется меньше времени для доставки, чем прежде, должно быть более чем достаточно, чтобы убедить их.

Во-первых, следует ценить ваше отношение и чувство искренности к качественной добавленной стоимости к деньгам клиента. И вот мои мысли о том, как вы можете убедить своего менеджера и клиента:

• Соберите показатели ошибок, которые вы исправляли, скажем, за последние 6 месяцев, а также минимальное, среднее и максимальное время, которое потребовалось вам, чтобы исправить ошибку.
• Для всех ошибок, которые вы исправили или имеете контекст, попробуйте написать модульные тесты, охватывающие эти области.
• Что касается ошибок, над которыми вы работаете, и тех, над которыми вы будете работать, попробуйте написать модульные тесты для этих областей еще до того, как внесете какие-либо изменения. Затем напишите код, чтобы выяснить причину и устранить ее. Посмотрите, не нарушит ли он какой-либо из ваших существующих тестов. Если да, то объясните и помогите своим коллегам понять важность модульных тестов.
• Как только все разработчики поймут важность модульных тестов, попросите их продолжать делать то, что вы делали в течение многих дней / недель.
• Со временем производительность групп должна улучшиться до такой степени, что и ваш менеджер, и клиенты будут удивлены темпами повышения производительности и качества кода. Это немного времени, но стоит попробовать.

Есть другой способ, и это попытка присоединиться к вашему менеджеру для участия в Agile конференциях, которые происходят вокруг. Это, безусловно, стоит посетить.

Если вы думаете, что ничего не работает, тогда идите дальше ... присоединяйтесь к месту, которое вам подходит. Откровенно, это то, что я сделал. Когда все не удалось, я двинулся дальше;)

И знайте, что модульные тесты после написания кода на самом деле не являются TDD, но тогда это всегда может быть первым шагом. Это так хорошо подходит здесь, по крайней мере.

Желаю удачи и успехов!