Мок-объекты для тестирования Java-систем

При тестировании программных артефактов с несколькими зависимостями можно либо инстанцировать эти зависимости, либо использовать мок-объекты для имитации их ожидаемого поведения. Хотя недавние количественные исследования показали, что мок-объекты широко используются как в проектах с открытым исходным кодом, так и в проприетарных проектах, научных знаний о том, как и почему практики используют моки, всё ещё не хватает. Эмпирическое понимание ситуаций, в которых разработчики применяют (и не применяют) моки, а также влияние таких решений на связанность и эволюцию ПО, может помочь практикам адаптировать и улучшать их последующее использование. С этой целью мы изучаем использование мок-объектов в трёх проектах с открытым исходным кодом и в одной промышленной системе. Конкретно, мы вручную анализируем более 2000 случаев использования моков, обсуждаем наши выводы с разработчиками из этих систем и выявляем практики, мотивы и проблемы. Эти результаты подтверждаются структурированным опросом более 100 специалистов. Наконец, мы вручную анализируем, как использование моков в тестовом коде эволюционирует во времени и каково его влияние на связанность между тестовым и продуктивным кодом. Наше исследование показывает, что использование моков сильно зависит от ответственности класса и архитектурных соображений. Разработчики сообщают, что часто мокируют зависимости, затрудняющие тестирование (например, инфраструктурные зависимости), и не мокируют классы, инкапсулирующие доменные концепции или правила системы. Среди ключевых проблем разработчики отмечают, что поддерживать совместимость поведения мока с поведением оригинального класса трудно, и что моки увеличивают связанность между тестовым и продуктивным кодом. Наши данные подтверждают эти представления: моки обычно присутствуют с самой первой версии тестового класса, как правило, остаются на протяжении всего его жизненного цикла, и изменения в продуктивном коде часто вынуждают вносить изменения и в тестовый код.