Отчет JUnit показывает функциональность тестирования, а не покрытие

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

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

После этого становится забыто, что тесты являются неполными, но они проходят и производят отличное покрытие кода. Запуск приложения и подача данных через него создадут высокие показатели покрытия кодов от Cobertura или Jacoco, но все же ничего не проверяется, кроме его способности работать без взрыва, - и я даже видел, что работала с большими блоками try-catch в тест.

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

Я был временно рад найти Jester, который тестирует тесты, изменяя тестируемый код (например, предложение if) и повторно запуская его, чтобы проверить, не нарушает ли он тест.

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

источник

2015-06-04 Adam

Можете ли вы привести конкретный пример того, что именно вы пытаетесь поймать? То есть пример, где покрытие кода теста велико, но качество теста плохое. – EJK

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

PIT является стандартным тестом на мутацию Java. На своем сайте:

Мутационные испытания концептуально просты.

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

...

Традиционное тестовое покрытие (т.е. линия, заявление, филиал и т.д.) только меры, код выполняется тестами. Он не проверяет, действительно ли ваши тесты обнаруживают ошибки в исполняемом коде. Поэтому он может только идентифицировать код, который определенно не проверен.

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

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

Качество ваших тестов может быть оценено из процента убитых мутаций.

У этого есть соответствующий Maven plugin, чтобы сделать его простым для интеграции как часть сборки CI. Я считаю, что следующая версия также будет включать правильную интеграцию с отчетами сайта Maven.

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

источник

2015-06-04 13:24:50

Я, очевидно, не добираюсь до достаточного количества devcons, потому что я мог бы долгое время использовать «PIT». Я успешно выполнил отчет за одну ночь - 1 час 30 минут, поэтому определенно не запускается, что при каждой регистрации исходного кода. Затем я проверил, чтобы узнать, какой уровень охвата был хорошим и нашел (теперь, когда я использую «тестирование мутаций» в качестве условия поиска), что [желательно 90%] (http://dev.theladders.com/2013/02/ мутация-тестирование-с-PIT-а-ступенчатого вне-нормальный код покрытие /). Таким образом, у нас есть способ пойти еще в этом проекте ..... – Adam

Да, это медленный процесс. Что вы можете сделать, так это создать отдельный профиль Maven с использованием некоторых фильтров, чтобы PIT просматривал только «опасные зоны» - пакеты, которые вас особенно волнуют, - и что один из них запускается чаще на вашем компьютере, отдельно от ночной сборки. –

Способ, которым я рекомендую использовать его (в первую очередь) локально при изменении кода. Если кодовая база является большой, используйте интеграцию управления версиями для анализа только измененных файлов или использования фильтров для уменьшения объема. – henry

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

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

источник

2015-06-04 13:27:42

Фактически это касается другой точки, которую я часто передумываю - в начале проекта, как вы можете написать хороший тест (ваша точка 2), когда большинство классов даже не существует, что вам нужно проверить? Я бы очень хотел написать те тесты, которые разработчики должны выполнить. – Adam

@Adam Даже при выполнении сольного программирования я часто пишу модульные тесты и комментарии Javadoc параллельно. Написание модульных тестов заставляет меня задавать вопросы, например: «Что должно произойти, если этот аргумент имеет значение NULL?», На который следует ответить в комментариях. –

Хороший вопрос, заданный оп. Хороший ответ Патрисии. Если вы действительно хотите серьезно относиться к Unit Testing, тогда попробуйте подталкивать его в цикле все больше и больше, пока вы не начнете писать тесты в первую очередь! Тесты по определению соответствуют спецификациям и правильной их перестановке, доказывая, что все работает на уровне метода, как предполагалось. Никакое кодирование перед тестами не записывается. –

-1

Похоже, что вам необходимо рассмотреть инструмент покрытия, например Jacoco, gradle plugin содержит отчет о покрытии. Я также использую плагин Eclipse EclEmma для получения тех же результатов, но с довольно хорошей интеграцией в IDE.

По моему опыту, Jacoco предоставил приемлемые номера, даже если нет единицы измерения единицы измерения. Похоже, что он способен точно определить проверенные коды кода. Тест No-op получает низкий или 0% очков покрытия, и оценка увеличивается по мере того, как тест становится более полным.

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

источник

2015-06-04 13:57:54

Не downvoter, но похоже, что тесты в OP не были не-ops. Они выполнили код и, таким образом, увеличили охват кода, однако не было никаких утверждений, поэтому, что бы код не делал, может быть неправильным – dkatzel

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

У вас есть различные варианты:

Вы, вероятно, могли бы использовать некоторый анализ кода инструмент, как Checkstyle, чтобы убедиться, что каждый тест имеет утверждение. Или, наоборот, используйте правило JUnit, чтобы проверить это, но оба легко обманываются и работают только на поверхностном уровне.
Испытание на мутацию, поскольку Jester делает снова техническое решение, которое будет работать, и, похоже, у @Tom_G есть инструмент, который может работать. Но эти инструменты (по моему опыту) очень медленные, потому что работа меняет код, запускает тесты, анализируя результат снова и снова. Таким образом, даже крошечные кодовые базы занимают много времени, и я бы даже не подумал об использовании его в реальном проекте.
Обзоры кода: такие плохие тесты легко пойманы обзорами кода, и в любом случае они должны быть частью каждого процесса разработки.

Все это еще только царапины на поверхности. Большой вопрос, который вы должны задуматься: почему разработчики испытывают соблазн создать код, чтобы запустить определенную часть приложения? Почему они не пишут тесты на то, что они хотят реализовать, поэтому почти нет необходимости запускать части приложения. Получите некоторую подготовку для автоматизированного модульного тестирования и, в частности, TDD/BDD, то есть процесс, когда вы сначала пишете тесты.

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

источник

2015-06-04 14:11:12

Действующие очки, но в моей ситуации вы не можете быть настолько оптимистичны в отношении способностей разработчиков, которые являются новыми для гибкого/TDD, особенно в среде, где подобные вам или я пытаюсь ретро-подгонять проект динозавров в проворную одежду , Логически люди могут распознавать принцип и быть в состоянии говорить об этом и обещать сделать это, но на самом деле делать это сложнее. – Adam

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

Хотя я не могу утверждать, что тестирование мутаций происходит быстро, современные инструменты, такие как PIT, буквально на порядок быстрее, чем ранние, такие как Jester. Теперь это совершенно практично для реальных кодовых баз.Например, полный анализ времени Джоды с PIT занимает около 3 минут (около 48 часов с чем-то вроде Jester). Даже с очень большими кодовыми базами анализ может быть ограничен только теми разделами текущего интереса (например, измененными файлами, о которых сообщает управление версиями). – henry

То, что вы ищете, действительно является испытанием на мутацию.

Что касается поддержки инструмента, вы можете также взглянуть на майора мутационный каркас (mutation-testing.org), который достаточно эффективен и настраивается. Major использует компилятор-интегрированный мутатор и дает отличный контроль над , что должно быть мутировано и проверено. Насколько я знаю, майор еще не создает графические отчеты, а файлы данных (csv), которые вы можете обрабатывать или визуализировать любым способом.

источник

2015-06-05 19:14:08

Отчет JUnit показывает функциональность тестирования, а не покрытие

ответ

Смежные вопросы