Пересмешка / Тестирование основного объекта в моей системе

Question

Меня попросили поработать над изменением количества классов, которые являются основными для системы, над которой мы работаем. Каждый из рассматриваемых классов требует от 5 до 10 различных связанных объектов, которым самим нужно примерно одинаковое количество объектов.

Данные также извлекаются из нескольких источников данных, и проект использует EJB2, поэтому при тестировании я запускаю без контейнера, чтобы получить нужные мне зависимости!

Я начинаю разбираться с этой задачей. Я пробовал юнит-тестирование с JUnit и Easymock, но как только я что-то высмеиваю или заглушаю, я обнаруживаю, что это требует гораздо большего. Кажется, что все довольно тесно связано, так что я достигаю 3 или 4 уровней с моими заглушками, чтобы предотвратить исключения NullPointerException.

Обычно с этим типом задачи я просто вносил изменения и проверял по мере выполнения. Но самый короткий цикл сборки составляет около 10 минут, и мне нравится кодировать с очень короткими итерациями между выполнениями (вероятно, потому что я не очень уверен в своей способности писать безупречный код).

Кто-нибудь знает хорошую стратегию / рабочий процесс, чтобы выбраться из этого трясины?

Answer 1

Как вы предполагаете, ваша основная проблема в том, что API, с которым вы работаете, слишком тесно связан. Если у вас есть возможность изменять API, может быть очень полезно скрыть непосредственные зависимости за интерфейсами, чтобы вы могли обрезать свой график зависимостей при непосредственной зависимости.

Если это невозможно, может помочь Контейнер для автоматической проверки . Это в основном контейнер, который автоматически выясняет, как вернуть макет с хорошим поведением по умолчанию для вложенных абстракций. Поскольку я работаю над платформой .NET, я не могу рекомендовать ее для Java.

Если вы хотите ознакомиться с шаблонами модульного тестирования и лучшими практиками, я могу порекомендовать только xUnit Test Patterns .

Для стратегий развязки тесно связанного кода я рекомендую Эффективная работа с устаревшим кодом .

Answer 2

Если ваш проект может быть скомпилирован с Java 1.5, посмотрите на JMock ? С версией 2. * этого фреймворка вещи можно довольно быстро заглушить.

1. * версия будет работать с компилятором Java 1.3+, но макетирование гораздо более многословно, поэтому я бы не рекомендовал его.

Что касается стратегии, я советую вам использовать интерфейсы. Даже если у вас есть единственная реализация данного интерфейса, всегда создавайте интерфейс. Они могут быть очень легко смоделированы и позволят вам намного лучше отделиться при тестировании вашего кода.

Answer 3

Первое, что я постараюсь сделать, это сократить цикл сборки. Возможно, добавьте в опции только сборку и тестирование компонентов, находящихся в стадии разработки.

Далее я бы посмотрел на разделение некоторых зависимостей путем введения интерфейсов между каждым компонентом. Я также хотел бы вытащить соединение в открытом виде, скорее всего, с помощью Dependency Injection. Если бы я не мог подвинуться к DI, у меня было бы два ctor, на no-arg ctor, который использовал сервисный локатор (или что там у вас) и один инъецируемый ctor.

проект использует EJB2, поэтому при тестировании я запускаю без контейнера, чтобы получить нужные мне зависимости!

Разве это не значит быть с? Я бы посмотрел на то, как можно больше в POJO, чтобы вы могли его протестировать без необходимости знать что-либо EJB-y.