Как вы можете убедиться, что все разработчики в вашей команде проверяют свой код? Показатели охвата кода - единственный способ, с помощью которого я могу объективно измерить это. Есть ли другой способ?Как убедиться, что разработчики тестируют свой код
(Конечно, если вы действительно следующий TDD, то это не должно быть проблемой. Но давайте предположим, у вас есть несколько разработчиков, которые не совсем «получить» TDD еще.)
Run отчеты о тестировании автоматически во время процесса сборки. Мы делаем это с CruiseControl. В противном случае вам необходимо проверить, что тестируется в отчетах о результатах тестирования.
Вам все еще нужно проверить тесты, чтобы убедиться, что тесты действительно действительны? – Kibbee
С nCover вы можете создавать минимальные показатели охвата, если тесты не достигают минимума, он выдает ошибку, которая не выполняет сборку. Это простой способ помочь в увеличении охвата устаревших приложений, а также в обеспечении охвата тестированием установленных проектов TDD. –
Имейте на регулярной основе отправку отчета или какой-либо экранный снимок результатов их модульных тестов. Они могут либо подделывать его (скорее всего, потребуется больше времени, чем на самом деле делать тесты), или на самом деле их делать.
В конце вы узнаете тех, кто не проводит тесты, они будут теми, у кого есть ошибки, которые можно было легко поймать с помощью модульных тестов.
Dumb da dumb dumb –
Здесь у нас есть тестовая папка с структурой пакета, отражающей фактический код. Чтобы проверить класс, политика заявляет, что он должен иметь сопровождающий класс тестирования, с определенными рекомендациями о том, какой/какой метод должен быть протестирован. (Пример: нам не нужны чистые геттеры и сеттеры, которые должны быть протестированы)
Быстрый взгляд на тестовую папку показывает, когда класс отсутствует, а оскорбительный человек может быть избит резиновым шлангом (или что-то в зависимости от ваша политика).
Таким образом, я могу (1) написать код ошибки, (2) попробовать различные тесты, пока не найду тот, который не поймает ни одного из моих ошибок, и проверьте этот тест. Правдоподобная отрицательность. – finnw
Несомненно, но тогда этот резиновый шланг возвращается, когда кто-то еще просматривает ваш код. –
Включите и измените случайную переменную или передайте нуль где-нибудь, и вы должны ожидать увидеть кучу красного. = D
Это не такая сумасшедшая идея. Создавая известные дефекты, вы можете получить оценку того, насколько хорошо работает ваш процесс QA, сравнивая количество найденных известных дефектов с # фактическими известными дефектами. –
Существуют инструменты для вставки ошибок и ошибок, которые можно использовать для автоматизации этого процесса, если хотите. –
Проблема такая же социальная, как и техническая. Если у вас есть разработчики, которые «не совсем» получают «TDD еще», то помогая им понять преимущества TDD, может быть лучшим долгосрочным решением, чем технические меры, которые «заставляют» их писать тесты, потому что это необходимо. Нежелательные разработчики могут легко писать тесты, которые соответствуют критериям покрытия кода, и все же не являются ценными тестами.
Это скорее социальная проблема, чем технологическая. Во-первых, вы хотите, чтобы модульные тесты приводили к 100% -ному охвату кода, или вы можете рассчитывать на меньшее, и доверять своим разработчикам, чтобы они вводили модульные тесты там, где они действительно важны, и где они имеют смысл. Вероятно, вы могли бы получить какую-то систему, которая провела бы тесты покрытия кода, чтобы гарантировать, что модульные тесты охватывают определенный процент кода. Но тогда все равно будут способы игры в систему. И это все равно не приведет к созданию кода, который был бы ошибкой. Из-за таких вещей, как проблема с остановкой, невозможно охватить всегда путь в коде.
+1 Я согласен, что не имеет смысла заставлять их с некоторой жесткой системой, они просто играли бы эту систему. Вы должны * объяснить им, насколько это важно.Это сложнее сделать, чем установить некоторый механизм принуждения, но, безусловно, более эффективен. – Frank
Инструменты покрытия кода почти наверняка превосходят любой специальный метод, который вы могли бы придумать. Вот почему они существуют.
Даже разработчики, которые получают TDD, далеко не защищены от пробелов в охвате. Часто код, который исправляет ошибку, ломает боковой тест или создает ветвь, которую первоначальный разработчик не ожидал, а разработчик обслуживания не понимал, был новым.
Хороший способ получить письменные тесты - увеличить подотчетность. Если разработчик должен объяснить кому-то еще точно , почему они не записывали модульные тесты, они, скорее всего, это сделают. Большинство компаний, с которыми я работал, потребовали, чтобы любые предлагаемые фиксации на магистраль были пересмотрены другим разработчиком перед фиксацией и чтобы имя рецензента включалось в комментарии коммита. В этой среде вы можете сообщить своей команде, что они не должны позволять коду «проходить» проверку однорангового кода, если не выполняются модульные тесты.
Теперь у вас есть цепочка ответственности. Если разработчик совершает код, не называя рецензента, вы можете спросить у них, кто просмотрел код (и, поскольку я усвоил трудный путь, должен сказать «никто» вашему боссу, когда его задали этот вопрос, это не весело!). Если вам стало известно о том, что код совершается без модульных тестов, вы можете спросить как разработчика , так и, что он не был рассмотрен в блоке. Возможность задать этот вопрос побуждает обозревателей кода настаивать на модульных тестах.
Еще один шаг, который вы можете предпринять, - установить фиксацию фиксации в вашей системе управления версиями, которая отправляет всю команду по электронной почте, когда совершается коммит, вместе с файлами и даже кодом, который составил коммит. Это обеспечивает высокий уровень прозрачности и далее поощряет разработчиков «следовать правилам». Конечно, это работает только в том случае, если оно масштабируется до количества, которое делает ваша команда в день.
Это скорее психологическое решение, чем техническое решение, но оно хорошо работает для меня при управлении командами программного обеспечения. Это также немного мягче, чем резиновый шланг, предложенный в другом ответе. :-)
Один из способов сделать это - написать скрипт для поиска всех проверок для термина «test» или «testfixture» (очевидно, в зависимости от вашей среды). Если есть журнал фиксации или электронное письмо, отправленное менеджеру, в котором были внесены изменения, то было бы тривиально с вашим любимым языком обработки текста сканировать файлы кода для признаков модульных тестов (ключевое слово Assert, вероятно, было бы лучший выбор).
Если нет единичных тестов, то во время следующего обзора кода возьмите пример недавней регистрации и проведите десять минут, говоря о возможных путях, которые он может «пойти не так», и о том, быстрее обнаружили ошибку.
wtf? почему это проголосовало бы? –
Я не уверен. Я думаю, они безумны, я не предоставил им плагин outlook или perl-скрипт, чтобы сделать это (есть множество способов поиска данных, я предусмотрел два). –
Одна вещь, которую следует упомянуть здесь, заключается в том, что вам нужна система для регулярного проведения модульных тестов. Они должны быть частью вашего мандата или системы ночной сборки. Простое удостоверение, что модульные тесты написаны, не гарантирует, что вы получите от них ценность.
Сядьте с ними и наблюдайте за тем, что они делают. Если они не тестируют устройство, аккуратно напомните им.
У меня есть проблема, связанная с внешними консультантами, которые делают небольшое приложение для нашей компании. Они утверждают, что были компетентными на tdd, но когда я хотел, чтобы они доставляли по крайней мере 85% на ncover, они начали говорить о том, как это займет гораздо больше времени, чтобы доставить наш продукт. Они не хотят доставлять более 65% покрытия, которые, как мне кажется, предполагают, что код будет практически непроверен в областях, так как я отправлюсь в отпуск по уходу за ребенком в середине проекта, я подозреваю, что моя команда получит довольно багги (остальная часть моей команды пока не сильна в tdd) – zzzuperfly