Читаю о необходимости сделать тестовое покрытие круда в 85%. Интересно, зачем в гуевом круде, работающем с БД, делать такое тестовое покрытие? Это правда нужно?
Мне кажется, тут есть какая‑то фундаментальная ошибка. unit‑test/database‑code impedance mismatch.
- юниты должны быть чистыми, изолированными. А база данных — это одна огромная stateful свалка. Даже если база у сделана не по...
... предметной области, и досталась не от соседей, а сдизайнена специально для твоего приложения, все равно она stateful. Исследование миграций между stateful и stateless — это тема для диплома, а не для повседневного быдлокодинга, на это просто нет времени.
- на моковой базе почти ничего интересного обычно не происходит. А при попытке сымитировать на ней настоящаю базу, получается тест сложнее кода, который (кроме предыдущего пункта) тестирует саму базу данных, сетевой стек, и кучу внешних систем — что угодно кроме твоего приложения
- даже если взять само приложение, большая часть кода и соответствующих ошибок находится не в твоем коде, а во фреймворке. ФреймворкАХ, тыщи их. Начиная тестировать специальные ситуации, по сути начинается тестирование фреймворка. И о чудо, его уже протестировали за нас! У хибернейта, спринг‑даты и прочего дофига тестов, до конца жизни столько не написать
- если выбросить описанные выше случаи, остается какой‑то элементарный код, тестирование которого не дает никаких осмысленных результатов. Вызвали delete на entity без возвращаемого значения и он не упал? Возьми с полки пирожок, и что ты из этого узнал?
делаю вывод следующий:
- круду нужно тестировать спецификацию, а не юниты. Внешнее интеграционное тестирование отдельных фич и всей приложухи сразу, в терминах предметной области.
- тестовое покрытие 85%, если это вообще зачем‑то нужно, задрачивать должны специальные разработчики тестов, а не обычные исполнители
−5
