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

Question

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

Код просто ужасный, но тесты никогда не улавливают его, потому что они утверждают (true).

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

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

Тесты C #, MbUnit.

Answer 1

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

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

Если вы не являетесь менеджером, то обратитесь к нему по соответствующим каналам.

Answer 2

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

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

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

Answer 3

Вам действительно следует указать язык / фреймворк, который вы используете.

В самом простом случае, я полагаю, это должно быть легко обнаружить assert(true) струны с простым grep-пинг.

Answer 4

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

Какие-нибудь тесты, которые прошли успешно, вызывают подозрение?

Answer 5

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

• Покажите ему, как писать лучшие тесты
• Заставьте его исправить свой код и предотвратите повторную проверку плохого кода

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

Answer 6

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

Answer 7

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

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

Пожалуйста, дайте нам знать, как у вас дела!

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

Answer 8

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

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

Попросите своих разработчиков объединить программу в пару, гораздо сложнее "лениться", когда вы работаете с кем-то еще над одной и той же функцией, и это распространит владение кодом по всему миру.Ты, кажется, этого не делаешь, раз говоришь о "его- код.Если над одной и той же работой будут работать 2 человека, Это значительно повысит качество.

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

Каковы ваши требования к обложке кода?