Коллега не желает использовать модульные тесты «так как это больше для кода»

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

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

Так какой же лучший путь для меня?

Она не знает о преимуществах модульного тестирования, и это то, что вам нужно изменить:

• Ее осознание.

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

Вы можете попытаться обсудить с ней все преимущества и выслушать все ее контраргументы. Подождите, пока она закончит говорить, прежде чем начать говорить самостоятельно.

Чтобы подготовиться, вы должны посмотреть на P.SE или Google, чтобы узнать обо всех вещах, которые руководство или разработчики беспокоятся о модульном тестировании, и скомпилировать ответы, которые вы будете использовать во время бесед с коллегой.

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

Напишите юнит-тест (не говорите ей)

Подождите, пока вещь сломается, дайте ей провести ручные тесты в течение двух дней, затем извлеките ваши юнит-тесты и найдите ошибку за три секунды.

Укрыться ...

Автоматизация в противном случае ручных задач должна понравиться любому программисту.

Поэтому она не «пишет больше кода», она делает меньше вручную.

(Один из) пункт (ы) автоматизированных испытаний является повторяемость . Если вы выполняете быстрый тест вручную, вы можете выполнить его быстрее, чем написать то же самое, что и модульное тестирование (по крайней мере, для начинающего модульного тестирования - любой, кто имеет опыт в модульном тестировании, может довольно быстро тестировать)

Но что, когда завтра или на следующей неделе в код будет внесено небольшое (или большое ...) изменение? Будет ли ваш коллега с удовольствием повторять одни и те же ручные тесты снова и снова после каждого изменения, чтобы убедиться, что ничего не сломано? Или она предпочла бы «код и молись»?

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

Если она в чем-то убеждена, но боится рисковать в новой области, предложите ей заняться парным программированием, чтобы написать свои первые модульные тесты вместе . Выберите класс, который не слишком сложен для тестирования, но достаточно сложен, чтобы его можно было проверить.

Однако, если она не убеждена, вам, возможно, придется собирать неопровержимые факты . Такие факты могут быть

• процент ошибок в коде, написанном вами против ее
• написание набора модульных тестов для ее кода и документирование найденных ошибок.

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

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

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

Чтобы играть адвокат дьяволов: у нее есть точка. Я обычно говорю это так:

Автоматические тесты решают проблемы, связанные с большим количеством кода и большим количеством кода.

Обоснование:

• исследование о соотношении частоты отказов и ОО метрик , заголовок результата: «После контроля размера [класса] ни одна из метрик, которые мы изучали, больше не была связана с дефектностью» . (В исследовании обсуждается размер класса. Распространяется ли этот эффект на размер базы кода? Возможно. На мой взгляд )
• Опытным путем крупные проекты, как правило, продвигаются медленно. «5 тысяч строк в новом проекте» против «10 строк в день на большом». Означает ли это, что «сопротивление» изменению увеличивается с увеличением размера базы кода?
• Мы всегда заявляем, что «лучшего языка нет, это зависит от проблемы». Одним из ключевых требований является легкое моделирование проблемных объектов и операций на выбранном языке. Разве это не говорит о том, что выбор языка, в котором выражение вашей проблемы является более сложным, хуже , и это опять же не соотносится с окончательным размером базы кода?

Теперь есть несколько аргументов, которые можно легко обстреливать. Позвольте мне упомянуть те, о которых я могу думать:

• размер против простоты: конечно, можно сделать код короче и хуже. Тем не менее, это только проблема при сравнении кодовых баз с различными соотношениями краткость-простота, для обсуждения можно предположить, что мы можем каким-то образом контролировать этот фактор.

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

TL; DR: я не утверждаю, что юнит-тесты плохие; Я спрашиваю: есть ли точка безубыточности, когда тесты вредят, что связано с количеством кода?

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

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

С другой стороны, у вас есть разработчик, который даже не осознал преимущества. А затем также коды спагетти код. Я полагаю, что одной из наиболее важных причин в данном конкретном случае является тот факт, что написание хороших модульных тестов вызывает слабосвязанную конструкцию. Так что заставить ее написать тест, возможно, в конечном итоге и улучшить «настоящий» код.

Но я думаю, что, в конце концов, это командное решение (я не знаю, сколько вас в команде?). Если команда может прийти к консенсусу о том, что должен быть хорошо охватывающий набор модульных тестов, то все должны соответствовать, делиться опытом и позволять вашей команде расти вместе.

Однако если команда не может прийти к общему мнению, что вам следует писать модульные тесты, я предлагаю вам найти другую группу разработчиков для работы;)

Она босс?

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

Она не начальник?

Каковы стандарты кодирования, где вы работаете? Почему ей разрешено извергать код спагетти? Представьте деловое обоснование начальнику, который скажет: «Мы потратим НАМНОГО меньше времени на ошибки, если потратим немного больше времени на TDD». Убедите кого-то, кто может принуждать к изменениям, с помощью бизнес-кейса.

Документируйте случаи, когда TDD мог бы сэкономить время и $$ ДЕНЬГИ $$.

Эта ошибка представила себя. Это было бы пойман, прежде чем начать жить. Трата 2 часов на профилактику спасла бы нас от 10 часов лечения. Это случилось здесь, здесь и здесь. Те 10 часов работы, которые сэкономили бы компании 30 человеко-часов. Вот столько денег.

Это оставляет меня в состоянии изменить что-то

Зачем?

Они создали проблему. Они должны решить это.

Какой менеджер позволяет этому случиться? Почему чужой глючный код теперь ваша проблема?

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

Ничего не изменится, если они не почувствуют боли низкого качества.

Она совершенно права, модульные тесты - это «больше кода».

Однако нужно просто написать больше кода, чтобы убедиться, что программа работает так, как должна (снова и снова). Это не потерянное время. Это такая же часть системы, как и ее основные компоненты.

Брось ей вызов:

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

Говоря как тот, который в настоящее время делает производственный код, сопровождаемый модульными тестами, а не TDD, который, кажется, не подходит для моего текущего места (я сделал TDD для некоторых проектов, но рассматриваю это как еще один инструмент в старая сумка, а не серебряная пуля) ...

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

Покажите ей, насколько помогают юнит-тесты, создавая юнит-тесты самостоятельно.

Как однажды сказал Святой Франциск: «Проповедуй всегда. Когда необходимо, используй слова».

Если она увидит, что ваш код использует модульные тесты и что вы можете быстрее решать ошибки с помощью модульных тестов, то это может изменить ее мнение. Но это не так.

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