Я не уверен, что универсальные инструменты покрытия - это Святой Грааль, по нескольким причинам:
- Покрытие - это не цель, это инструмент. Он говорит вам, какие части кода не полностью поражены тестом. О том, насколько хороши тесты, ничего не говорится.
- Сгенерированные тесты не могут угадать семантику вашего кода. Фреймворки, которые генерируют тесты только для вас, могут вывести значение из чтения вашего кода, что, по сути, может быть неверным, потому что весь смысл юнит-тестирования заключается в том, чтобы увидеть, действительно ли код ведет себя так, как вы и предполагали.
- Поскольку автоматизированная инфраструктура будет генерировать искусственное покрытие, вы никогда не сможете сказать, тестируется ли фрагмент кода с помощью правильного юнит-теста или поверхностно тестируется платформой. Я предпочел бы, чтобы непроверенный код отображался как непокрытый, поэтому я исправляю это.
Что вы могли бы сделать (и я сделал ;-)) - написать общий тест для тестирования Java-бинов. С помощью отражения вы можете протестировать Java-бин на соответствие спецификации Sun Java-бина. Утвердите, что equals и hashcode оба реализованы (или ни один из них), посмотрите, что получатель фактически возвращает значение, которое вы указали с помощью установщика, проверьте, все ли свойства имеют методы получения и установки.
Вы можете сделать один и тот же базовый трюк для всего, что реализует «сопоставимый», например.
Это легко сделать, легко обслуживать и вынуждает вас иметь чистые бобы. Что касается остальной части юнит-тестов, я стараюсь сосредоточиться на тестировании важных деталей в первую очередь.
Покрытие может дать ложное чувство безопасности. Здравый смысл нельзя автоматизировать.