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

25

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

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

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

billy.bob
источник
3
Отвращение к написанию модульных тестов, возможно, связано не столько с вашим коллегой, сколько с системными издержками реализации общих модульных тестов.
Марио
2
@james: Пожалуйста, посмотрите мой ответ на @ m.edmondson.
doppelgreener
Хорошо!! Меньше конкуренции для тебя!
@Jonathan - честно говоря, я поправляюсь
ozz
@ m.Edmondson - новая работа .... это была часть моего комментария, но это звучит как непристойное место для работы, старые технологии, разработчики, не желающие использовать разумную практику разработчиков.
Оз

Ответы:

23

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

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

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

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

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

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


источник
20
Люблю список из одного предмета. +1
Арманд
1
Этот ответ был бы идеальным, если бы вы остановились сразу после списка. +1 :)
Тим Пост
Привет, Тим, поздравляю тебя с 2-й позицией на SO выборах!
6
Я чувствовал, что этот список заслуживает своей собственной круговой диаграммы.
Томас
Вам также может понадобиться изменить ее готовность отправлять ошибки. Некоторое избежание дефектов может сделать более качественное тестирование более важным.
Stonemetal
15

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

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

Укрыться ...

Торстен Мюллер
источник
1
+1 Для указания на то, что ошибки неизбежны, и для укрытия.
Нил
+1 Написание полного набора модульных тестов для одного конкретного фрагмента кода может выявить достаточно проблем с кодом, которые в любом случае демонстрируют преимущества. Я помню, как смотрел презентацию о том, как можно использовать модульные тесты для поддержки спецификаций / поведения интерфейса / API посредством полной переписывания кода ...
JBRWilkinson
3
@JBRWilkinson: Merb (бывший каркас веб-приложений Ruby) сделал именно это. Не с юнит-тестами, а с функциональными тестами. Архитектура выросла «органично», и хотя фреймворк был приятным в использовании , его было не очень приятно поддерживать и расширять . А поскольку ремонтопригодность и расширяемость фактически были двумя главными преимуществами по сравнению с конкурентом Ruby on Rails, им, очевидно, нужно было что-то с этим делать. И они буквально обращались к rm -rfкаталогам исходного кода и модульных тестов, сохраняя только функциональные тесты, и просто заставляли их проходить снова один за другим.
Йорг Миттаг
11

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

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

Les
источник
1
зависит, есть ли у вас тестовая команда, которая сделает все это за вас :)
gbjbaanb
11

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

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

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

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

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

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

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

Петер Тёрёк
источник
Весьма маловероятно - хотя
нередко и
@ m.edmondson, да, это был просто риторический вопрос :-)
Péter Török
+1 за повторяемость. Я агрессивный рефакторинг (er), и мне нравится тот факт, что я могу очень быстро находить регрессии, когда полностью переписываю часть кода.
Майкл К
3

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

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

TZHX
источник
Мы находимся на .NET 1 (шутка, которую я знаю) - могут ли здесь быть реализованы юнит-тесты?
billy.bob
1
@ m.edmondson: Возможно, что-то вроде NUnit? ( nunit.org )
доктор Ганнибал Лектер
@dr Ганнибал Лектер - Да, я думаю, у нас где-то есть копия, и я посмотрю, смогу ли я ее найти
billy.bob
4
модульные тесты не должны использовать определенный набор, чтобы быть эффективными. Я написал их только на python, делая вызовы для программы на c ++ и проверяя полученные значения. фреймворк, конечно, помогает, но это не обязательно.
TZHX
3

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

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

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

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

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

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

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


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

peterchen
источник
2

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

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

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

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

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

Пит
источник
2

Она босс?

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

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

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

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

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

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

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

Зачем?

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

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

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

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

С. Лотт
источник
> Они создали проблему => Они должны решить ее. Иногда самые близкие к холсту люди не видят всей картины. Написание модульного теста будет выполнять небольшую работу, но не обязательно очищать работу других. Возможность подавать пример.
JBRWilkinson
1
@JBRWilkinson: Хотя это правда - и то, что я часто делаю - это не влияет на культурные изменения. Если кто-то отказывается делать тесты, существует культура, которая делает этот отказ (а) возможным и (б) подкрепляется хорошим поведением. Молча взяв на себя бремя исправления чужого беспорядка, не устранит первопричины.
S.Lott
Хотя я согласен с тем, что для членов команды было бы неприемлемым просто набрасывать дерьмовый код и рассчитывать на то, что другие имеют дело с их беспорядком, я думаю, что вредно принимать ментальность "если ты ее сломаешь, тебе принадлежит". Вы не хотите, чтобы люди боялись изменять и улучшать код. Вместо этого сосредоточьтесь на распространении передового опыта и постройте надежный набор тестов. Тогда вы можете работать в направлении более «совместного владения» мышления. Это код каждого. Все это исправляют, все улучшают и несут ответственность.
Сара
1

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

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

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

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

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

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

Брайан Кноблаух
источник
1

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

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

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

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

Джордж Стокер
источник