Что я должен сделать, когда коллега отклоняет мои фиксации, потому что они содержат модульные тесты?
Я переместился от одной команды к другому в той же компании. В старой команде (жесткий C++) мы сделали большое поблочное тестирование. В моей новой команде (также C++) они делают функциональное тестирование вместо этого. Во время обзора они отклоняют мой код из-за модульных тестов. Большинство команд интересуется изучением чего-то нового, но не парня, который является VIP и сделал, чтобы разработчик прежней версии приблизился. Он должен принять код перед фиксацией. Он сопротивляется изменению. Совет?
//обновление: я сообщу в этой теме, что произошло с моими поисками, но поймите, что это - крупная компания, это занимает время. Просто для уточнения тесты, которые я делаю, прекрасны, и это всегда работало в других командах. Я не плохо знаком с этим. Время от времени я должен тормозить, причина зависимостей кодируют его простое дерьмо. В C++ Вы иногда имеете к. Это может представить изменение в коде напоминания только из-за теста. Я полагаю, что наличие модульного теста выравнивает по ширине этот вид простых изменений. Лучше иметь его, чем нет.
//update2: Спасибо за большой хороший совет ясно здесь нет никакой серебряной пули :( Большинство команд убеждено, но 2 старших (15 лет +) devs все еще противостоящие. Я сделаю короткий доклад на этой остальной части моей команды, будет поддерживать меня так, я надеюсь, что те парни просто согласятся :) Для ослабления немного, я начал изучать рубин :)
17 ответов
Вы только что столкнулись с самой сложной программной проблемой: люди. Хотя я не решаюсь подвергать сомнению вашего босса без какого-либо дополнительного контекста (например, действительно ли это полная картина тестирования?), Прямой отказ от вашего кода только потому, что вы включили модульные тесты, в лучшем случае является сомнительной практикой.
Самый разумный способ - поговорить с этим человеком один на один, чтобы понять его позицию. Вы описываете своего босса как стойкого к переменам, но обычно люди не такие уж черно-белые. Например, возможно, он считает объем отправляемого вами кода рискованным, учитывая ваш новый статус в проекте, не понимая, что ваше модульное тестирование позволяет вам писать больше кода, потому что вы можете быть более уверены в нем. Так что я бы дал ему преимущество сомнения и сначала поговорил по душам.
Вот несколько вопросов, которые следует задать во время разговора:
Что вы думаете о модульных тестах? Как они вписываются в нашу общую стратегию тестирования?
Какие у вас проблемы с модульными тестами, которые я отправляю? Они в чем-то недостаточны или отсутствуют? Вы согласны с самим модульным тестированием, но предпочли бы, чтобы мой код был организован по-другому?
Почему весь наш код должен быть протестирован на функциональном уровне?
Все ли модульные тесты плохи или не подходят для нашего проекта?
Как вы планируете обнаруживать проблемы, связанные с конкретными входными данными для методов, когда эти условия сложнее воспроизвести на более высоких уровнях интерфейса?
Если у вас есть конкретное возражение против проверки модульных тестов, есть ли возражения против использования юнит-тесты локально, чтобы я мог по крайней мере проверить свой собственный код?
Если вы чувствуете, что теперь понимаете его позицию, и это несостоятельно с тем, как вы хотите писать программы, у вас есть другой вопрос, который следует задать себе: нравится ли вам работы, достаточной для того, чтобы оставаться в команде, несмотря на сомнительные с профессиональной точки зрения практики, или пора ли искать в другом месте?
И наоборот, если вы чувствуете, что теперь понимаете, почему существует правило, и считаете его разумным в свете общий контекст проект, тогда ура! Вы избежали потенциального кризиса, работая профессионально, вы остаетесь в своей новой команде и можете вернуться к самой интересной части: разработке программного обеспечения.
Edit: Я действительно не могу согласиться с некоторыми сообщениями в этом вопросе, в которых OP должен адаптироваться к команде.Стандартизация практик хороша только тогда, когда команда покупает на практике. Вместо того, чтобы говорить ОП, чтобы тот впитал его и встал в очередь, мы должны побудить его понять , почему правило действует, чтобы он мог оценить, имеет ли оно смысл по существу.
У менеджера также есть некоторые объяснения, чтобы он мог помочь оператору увидеть вещи по-своему. Конечно, не все всегда будут соглашаться с менеджерами. Я руководил проектами или командами и принимал решения, которые не могли понравиться всем, но я всегда старался принимать их в первую очередь при участии всех, чтобы я мог прийти к наилучшему решению. На мой взгляд, соблюдение набора «стандартов» управленческим указом без учета влияния на команду и игнорирования альтернативных предложений делает вас плохим менеджером, а не хорошим.
С другой стороны, причина, по которой модульные тесты могут быть отклонены рецензентом, может быть следующей:
- Вероятно, правила применяются ко всему коду в проекте
- Это означает, что модульные тесты означают, что нужно проверять гораздо больше кода.
- Модульные тесты могут быть написаны не в соответствии с общими стандартами проверки / кодирования.
Особенно на C ++, я полагаю, что ваши тесты как бы смешиваются с основными код приложения, поскольку в проекте уже нет настройки модульного тестирования. В этом случае это может затруднить выполнение кода.
Переименуйте свои модульные тесты в "функциональные тесты камеры".
РЕДАКТИРОВАТЬ: На практике, если вы не можете преодолеть человеческий фактор, вы можете поддерживать свои модульные тесты в небольшом частном параллельном репозитории. Распакуйте их при разработке или сопровождении, запустите, обновите и отложите до следующего раза.
Храните модульные тесты в параллельном управлении версиями и отправляйте код только в центральную систему. Он проверит ваш код без модульных тестов, и вы все равно сможете извлечь из них пользу ...
Кроме того, я предлагаю использовать один из распределенных элементов управления версиями, вы можете поиграть с новой забавной игрушкой, и когда одна из ваших другие сотрудники хотят попробовать, он может легко охватить и расширить ваш набор тестов.
Изменить Чтобы прояснить следующие комментарии:
Я предлагаю ему создать локальный репозиторий исходного кода для своих модульных тестов. Сам код по-прежнему будет синхронизироваться с управляемым репозиторием (через обычный процесс отправки, просто не отправляя тесты вместе с кодом).
Он также может хранить полезные модульные тесты на своем жестком диске, и это ничего не изменит, точно так же, как у любого моего знакомого разработчика есть несколько "инструментальных" файлов для различных целей.
Идея состоит в том, что работая с модульными тестами, он может надеяться на то, что его коэффициент ошибок будет ниже, чем у других. Это может помочь в споре о подобных вещах с его техническим руководителем. Пока он выполняет порученную работу вовремя, я не понимаю, почему он не мог работать так, как считает нужным.
Продолжайте писать эти тесты, но избегайте написания тривиальных тестов. Может быть, с помощью тривиального теста вы думаете, что можете обучить других, но они могут рассматривать его как доказательство того, что вы тратите время. Попробуйте исправить ошибки, написав тест, чтобы воспроизвести проблему и сделать презентацию о том, что вы сделали для команды. Старайтесь не продавать модульное тестирование как новую религию, но постарайтесь объяснить, почему вы так работаете. Сначала потратьте свою энергию на то, чтобы убедить других членов команды.
В какой-то момент они заметят, что вы можете вносить большие изменения в реализацию своего кода без регресса.
Модульные тесты имеют затраты, а не только преимущества. Из http://www.joelonsoftware.com/items/2009/09/23.html :
Завински не проводил много модульных тестов. Они «в принципе звучат великолепно. . Учитывая неторопливые темпы разработки, это, безусловно, путь. Но когда вы смотрите на "Нам нужно перейти с нуля до завершения за шесть недель", что ж, я не могу этого сделать, пока не порежу что-то . И я собираюсь исключить то, что не является абсолютно важным. А модульные тесты не критичны. Если нет модульного теста, клиент не будет жаловаться на это ».
От: http://www.codinghorror.com/blog/2005/04 /good-test-bad-test.html
Моя основная проблема на данный момент с модульными тестами заключается в том, что когда я меняю дизайн, я получаю стопку неудачных тестов. Это означает, что я либо буду писать меньше тестов, либо буду вносить меньше серьезных изменений в дизайн. И то, и другое - плохие вещи.
Через несколько минут вы получите ответы, в основном благоприятные для вас. Покажите эту ветку тому человеку, который сопротивляется коду. :)
Самое важное в команде разработчиков - придерживаться стандартов, даже если вы не согласны со стандартами. Если каждый занимается своим делом, тогда нет смысла устанавливать стандарты.
Вы можете сохранить модульные тесты для вашего личного удовлетворения / уверенности. Возможно, однажды вы сможете продемонстрировать, что ваш подход предотвратил повторное появление ошибки или каким-то образом принес пользу команде, и тогда вам будет легче донести свою точку зрения.
Однажды вы будете парнем, устанавливающим стандарты, и тогда некоторые люди не согласятся с вами. Тогда вы можете рассказать им эту историю.
Заявление об ограничении ответственности: я использую модульные тесты, когда это необходимо, и всем, кто работает на меня, также будет рекомендовано это сделать.
Я собираюсь предложить менее драматичную версию ответа Джона Феминеллы.
Поговорите с человеком, о котором идет речь, но не делайте из этого большой песни и танца. Конечно, не стоит говорить: "Почему вам не нравится, что я делаю что-то, что делает мой код лучше", это бросает вызов его знаниям, а учитывая, что многие разработчики довольно чувствительны к подразумеваемой критике, он может просто сказать вам, чтобы вы убирались.
Вместо этого я бы сначала уточнил: "Вы провалили обзор только потому, что я включил этот тестовый код?". Затем скажите: "Я нахожу, что моя производительность выше, когда я пишу тесты, в чем проблема проверить тесты"
.Интересно, что код был отклонен из-за модульных тестов. Если бы вы исключили их из кода, который вы отправили для принятия, было бы ли это принято? Если это так, вы просто продолжаете выполнять модульные тесты и продолжаете выпускать производственный код, который проходит эти модульные тесты. Если ваши тесты хороши, они только улучшат производственный код, который вы вводите. «Накладные расходы» на написание модульных тестов не так уж велики - конечно, по сравнению с поиском ошибок ниже по течению.
Тем не менее, вы не можете войти в новую группу и ожидать, что измените культуру группы в одночасье - этого обычно не происходит. Лучше, если вы будете в курсе своих передовых практик и отправите код, который пройдет ваши тесты. Со временем может прийти к вам коллега или правила могут измениться. Люди не хотят меняться, пока не увидят выгоды.
Если ваш код не соответствует какому-либо другому стандарту, установленному группой, вам, конечно же, необходимо заняться этим.
Мне кажется, что он отказывается проверять источники, содержащие код для выполнения модульных тестов, верно?
Простое решение для этого - не пытаться проверять код для выполнения модульных тестов. Вы все равно можете писать его и выполнять модульные тесты, но держите их отдельно. Если вы хотите контролировать ревизию, создайте отдельный репозиторий для своих модульных тестов.
Именно так я делал это большую часть своей 20-летней карьеры. Думаю, я работал только над одной программой, в которой официально отслеживались модульные тесты, как это делала ваша старая группа.
Пусть руководитель вашей команды прочитает эту статью (pdf) (которую вы можете найти в этой записи блога) и посмотрите, не изменит ли он своего мнения.
Итак, одно исследование ничего не доказывает, но в нем есть один очень интригующий абзац:
Мы обнаружили, что студенты, стремящиеся к тестам, в среднем пишут больше тестов и, в свою очередь, пишут больше тестов. в среднем пишут больше тестов и, в свою очередь, студенты, которые писали больше тестов, как правило. были более продуктивными. Мы также заметили, что минимальное качество линейно возрастало с количеством программистских тестов, независимо от от применяемой стратегии разработки.
Другими словами, лучше тесты - лучше код. Точка. (Это совпадает с моим опытом и опытом бесчисленных разработчиков, с которыми я работал).
Если вы не можете заставить этого парня изменить свое мнение, то ищите работу в другом месте - вы попали в одну из тех команд неудачников, где ответственные лица невосприимчивы к обучению чему-то новому. Нехорошо.
EDIT: существуют десятки исследований, показывающих эффективность TDD. Попробуйте посмотреть здесь и здесь.
Один из хороших советов, который я получил на университетской лекции по качеству программного обеспечения:
Если вы попали в команду/компанию, где действительно не знают, как делать программное обеспечение. Попытайтесь помочь им улучшить качество (согласитесь, что нет одного хорошего способа, но не пытаться - не выход). Придумайте хорошие аргументы (например: в моем коде меньше ошибок, а времени на написание уходит столько же?). Если вы не можете сменить компанию/команду: Не оставайтесь, начните искать новую работу, в этой или другой компании.
Я ленивый ублюдок, который нигде не пишет достаточно модульных тестов, но я не настолько идиот, чтобы отказываться от модульных тестов, когда мои ребята прилагают усилия для их написания. Вы можете попробовать работать в рамках глупого руководства, но если нет надежды, что этот парень скоро исчезнет со сцены, я предлагаю вам найти другую команду.
Это не совсем ответ на ваш вопрос, но вы не упомянули, получаете ли вы покрытие кода.
Функциональное тестирование плюс покрытие кода могут быть эффективными для демонстрации правильности кода и, возможно, были популярны, когда ваш менеджер продвигался по служебной лестнице.
Основная проблема в том, что это требует больших усилий и не очень практично, когда ваш код все еще находится в движении.
Если команда не имеет опыта в сопровождении набора модульных тестов, то у них есть проблема, но вы вряд ли сможете ее решить, если он важнее в компании, чем вы.
Извините, но вам придется адаптироваться к команде. Вам придется часто говорить с ними о модульном тесте, вы не сможете убедить их за один день.
Мой начальник ничего не знал о oop, и он все еще программировал на C #, теперь убедил его использовать конструктор, возможно, через несколько месяцев он будет использовать частное поле / метод вместо статического метода.
адаптируйтесь.