Правильный юнит тест

Question

Правильный юнит тест

1

Я не совсем уверен, соответствует ли этот вопрос стандартам SO, но...

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

Я нашел то, что похоже на то, что я хочу достичь - GrandTestAuto (вдохновение пришло на странице инструментов тестирования), можете ли вы порекомендовать другой (лучший) подход?

Я должен проверить его (GTA) больше, меня интересует Spring, Mocking, Maven, чтобы работать вместе, но я немного скептически настроен.

Я также использую отчеты о покрытиях (JCoverage, JaCoCo), но это неточно, потому что когда вы тестируете метод a() который вызывает b() оба они покрываются, но в качестве разработчика я хочу написать тесты для b().

редактировать:
Я нашел отчет JUCA, мне тоже нужно проверить это.

edit2:
Хорошо, идея о a() вызовах b() должна быть больше.

Смотрите пример

void a() {
    b( "test" );
}

void b( String s ) {
    Assert.notNull( s );
    // ...
}

когда a() покрывается, также покрывается b(), но случай, когда s равен null, не является, и это часто происходит, потому что b() вообще не проверяется.

Betlista 01 май 2014, в 12:48

Источник

1

В конце концов, слишком просто играть в инструменты покрытия, поэтому вам нужны хорошие разработчики для написания хороших модульных тестов - попытка заменить навык инструментами не даст того же результата
Nick Holt 01 май 2014, в 11:58
1

Если метод а () вызывает метод Ь (), оба покрыты. Я думаю, что вы спрашиваете, можете ли вы убедиться, что метод b () тестирует напрямую? @NickHolt прав, инструменты не могут заменить навыки и опыт
tddmonkey 01 май 2014, в 12:26
0

Это не попытка «заменить навык инструментом», но, как я уже сказал, у меня есть метод a() и проверка на него. a() вызывает b() в выпуске 1.0, но в выпуске 1.1 a() также вызывает c() и я не хочу забывать написать тест для c() также ...
Betlista 01 май 2014, в 14:16

Показать ещё 1 комментарий

Теги:

java

unit-testing

1 ответ

Ещё вопросы

В конце концов, слишком просто играть в инструменты покрытия, поэтому вам нужны хорошие разработчики для написания хороших модульных тестов - попытка заменить навык инструментами не даст того же результата
Если метод а () вызывает метод Ь (), оба покрыты. Я думаю, что вы спрашиваете, можете ли вы убедиться, что метод b () тестирует напрямую? @NickHolt прав, инструменты не могут заменить навыки и опыт
Это не попытка «заменить навык инструментом», но, как я уже сказал, у меня есть метод a() и проверка на него. a() вызывает b() в выпуске 1.0, но в выпуске 1.1 a() также вызывает c() и я не хочу забывать написать тест для c() также ...

eitanfar · Answer 1 · 2014-05-01T10-30-00.000Z

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

Я предлагаю две вещи:

Обзор тестов - такие же, как и для отзывов о кодах, но для кода теста. Вы не поверили бы, насколько эффективно это
Mutation Testing - автоматические инструменты, которые изменяют производственный код во время выполнения и проверяют, что тесты, охватывающие его, не работают. Я работаю с PIT (http://pitest.org/) и очень рекомендую