Что делать, если сотрудник отклоняет мои коммиты, потому что они содержат модульные тесты?

Ответ 1

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

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

Вот несколько вопросов, которые нужно задать во время разговора:

• Что вы думаете об модульных тестах? Как они вписываются в нашу общую стратегию тестирования?

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

• Почему весь наш код должен тестироваться на функциональном уровне?

• Все тесты модулей плохо или неуместны для нашего проекта?

• Как вы планируете обнаруживать проблемы, связанные с конкретными входными данными для методов, когда эти условия сложнее реплицировать на более высоких уровнях интерфейса?

• Если у вас есть специальное возражение против проверки модульных тестов, существует ли какое-либо возражение против использования модульных тестов локально, чтобы я мог хотя бы проверить свой собственный код?

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

И наоборот, если вы чувствуете, что теперь понимаете, почему это правило существует, и вы думаете, что это разумно в свете общего контекста проекта, то хасха! Вы избегали потенциального кризиса, профессионально обрабатывая себя, вы можете остаться с новой командой, и вы вернетесь к интересной части: разработка программного обеспечения.

Изменить: Я действительно не могу согласиться с некоторыми сообщениями в этом вопросе, говоря OP, чтобы адаптироваться к команде. Стандартизация практики хороша только тогда, когда команда покупает практику. Вместо того, чтобы сообщать ОП о том, чтобы сосать его и впасть в линию, мы должны поощрять его понять, почему правило существует, чтобы он мог оценить, имеет ли он смысл по существу.

У менеджера также есть некоторые объяснения, чтобы сделать так, чтобы он мог помочь OP видеть вещи своим путем. Конечно, не все согласятся с менеджерами все время. Я руководил проектами или командами, и делал свою долю решений, которые не могли понравиться всем, но я всегда старался сделать их с помощью первого, чтобы я мог прийти к лучшему решению. На мой взгляд, применение набора "стандартов" с помощью управленческих решений без учета влияния на команду и игнорирования альтернативных предложений делает вас плохой менеджер, а не хороший.

Ответ 2

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

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

Edit Чтобы прояснить следующие комментарии:

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

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

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

Ответ 3

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

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

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

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

Ответ 4

У блочных тестов есть издержки, а не только выгоды. Из http://www.joelonsoftware.com/items/2009/09/23.html:

Zawinski не проводил много модульных тестов. Они "отлично звучат в принципе. неторопливый темп развития, thats конечно, путь. Но когда youre смотрящ на," Weve, котор нужно пойти от нуля до шести недель, ну, Я не могу это сделать, если не отрежу что-то вне. И то, что я собираюсь вырезать, - это материал, который не совсем критичный. И модульные тесты не критичный. Если theres no unit testклиент не собирается жаловаться что ".

От: http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html

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

Ответ 5

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

Ответ 6

Извините, но вам придется приспособиться к команде. Вам придется часто говорить о них unit test, вы не можете убедить их в один день.

Мой начальник ничего не знал о oop, и он все еще программировал в С#, теперь убедил его использовать конструктор, возможно, через несколько месяцев он будет делать private field/method вместо статического метода.

приспособитесь.

Ответ 7

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

Ответ 8

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

Теперь одно исследование ничего не доказывает, но есть один очень интригующий абзац:

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

Другими словами, лучшие тесты, лучший код. Период. (Это квадраты с моим опытом и опытом многих других разработчиков, с которыми я работал).

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

EDIT: проводятся десятки исследований, показывающих эффективность TDD. Попробуйте здесь и здесь для большего.

Ответ 9

Если у команды нет опыта в тестировании units, то у них есть проблема, но вы вряд ли сможете ее решить, если он более важен в компании, чем вы.

Ответ 10

Переименуйте тесты на устройства "функциональные тесты камеры".

РЕДАКТИРОВАТЬ: Более практично, если вы не можете преодолеть человеческий элемент, вы можете поддерживать модульные тесты в небольшом частном параллельном хранилище. Распакуйте их, когда вы разрабатываете или обслуживаете, запускаете их, обновляете, а затем откладываете до следующего раза.

Ответ 11

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

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

Ответ 12

Один из хороших советов, которые я получил во время университетской лекции о качестве программного обеспечения:

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

Ответ 13

Мне кажется, что он отказывается проверять источники, содержащие код для выполнения модульных тестов, правильно?

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

Вот как я сделал это большую часть моей 20-летней карьеры. Я думаю, что только когда-либо работал над одной программой, которая официально отслеживала модульные тесты, как и ваша старая группа.

Ответ 14

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

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

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

Ответ 15

Я собираюсь предложить менее драматичную версию ответа Джона Фэминеллы.

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

Вместо этого я сначала уточню: "Вы только отказали в просмотре, потому что я включил этот тестовый код?" Затем скажите: "Я нахожу, что моя производительность выше, когда я пишу тесты, в чем проблема, которую я проверяю в тестах"

Ответ 16

С другой стороны, модульные тесты причины могут быть отклонены рецензентами:

• Скорее всего, правила распространяются на весь код проекта
• Это означает, что модульные тесты означают гораздо больше кода для просмотра
• Модульные тесты не могут быть написаны так, чтобы соответствовать общим стандартам обзора/кодирования.

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

Ответ 17

Это не относится к вашему вопросу, но вы не указали, получаете ли вы покрытие кода.

Функциональное тестирование плюс покрытие кода может быть эффективным в демонстрации правильности кода и, возможно, было популярным, когда менеджер посещал ряды.

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