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

Question

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

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

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

Есть ли плагин для сборки тестов, которые не могут быть неудачными?

C #, mbUnit тесты.

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Есть ли какие-либо тесты, которые проходят, являются подозрительными?

Answer 8

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

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