Идеи покрытия кода Java? - PullRequest
       15

Идеи покрытия кода Java?

4 голосов
/ 28 октября 2011

Я работаю над проектом Java, где у меня есть сборка ant, которая запускает тесты JUnit, которые контролируются Cobertura. Это прекрасно работает, и мы сохранили наш охват очень высоко. Для некоторых классов, таких как объекты Hibernate, у нас есть минимальный код, но есть методы equals и hashCode. Тестирование это огромная боль и снижает процент охвата. Мы попытались использовать EqualsVerifier , два класса имеют ссылки друг на друга, что часто происходит в сущностях Hibernate.

Мы рассмотрели возможность использования Commons EqualsBuilder, но затем мы теряем возможность автоматически генерировать в IDE методы equals / hashCode. Я знаю, что EqualsBuilder также может быть реализован с помощью рефлексии, но мы не хотим терять производительность во время выполнения только для покрытия модульных тестов во время сборки.

Идеальная ситуация была бы, если бы мы могли сказать Cobertura просто игнорировать методы equals и hashCode, но патчи требуют от нас аннотирования наших классов, что немного неловко.

Итак, я надеюсь на идеи от других относительно того, что хорошо работает в таких случаях. У кого-нибудь есть идеи, как это сделать?

Спасибо!

Ответы [ 2 ]

5 голосов
/ 28 октября 2011

Мне кажется, что вам нужно принять решение: либо equals и hashCode не важны, и в этом случае вам следует просто проигнорировать <100% показатель покрытия кода (или выяснить, как игнорировать метод). Или они важны, и вы должны написать модульные тесты для их тренировки. Это может быть не весело, но, похоже, вам все равно, правильно ли работают эти методы. В этом случае вам, вероятно, нужно проверить их. </p>

1 голос
/ 28 октября 2011

Если тестирование не стоит, то, во-первых, не стоит писать код.

Другими словами: если ваши методы equals и hashcode используются где-либо в вашем рабочем коде, то вы нужно покрытие кода.Так просто.Иначе это вызовет ошибки.Поверьте мне, это будет .

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

...