Первый постер и TDD усыновитель. :-) Я буду немного многословен, поэтому, пожалуйста, потерпите меня.
Недавно я начал разработку веб-сервисов на основе SOAP с использованием инфраструктуры Apache CXF, Spring и Commons Chain для реализации бизнес-процессов. Проблема, с которой я здесь сталкиваюсь, заключается в тестировании веб-сервисов - тестировании как в модульном тестировании, так и в функциональном тестировании.
Моя первая попытка модульного тестирования была полным провалом. Чтобы обеспечить гибкость модульных тестов, я использовал файл Spring XML для хранения своих тестовых данных. Кроме того, вместо создания экземпляров «компонентов» для тестирования, я извлек их из контекста моего Spring-приложения. XML-файлы, содержащие данные, быстро вышли из-под контроля; создание графов объектов в XML оказалось кошмаром. Поскольку «компоненты», подлежащие тестированию, были выбраны из контекста приложения Spring, при каждом запуске теста загружалось все компоненты, используемые в моем приложении, используемые объекты DAO и т. Д. Кроме того, в отличие от концепции модульного теста когда дела были централизованы или сконцентрированы на тестировании только компонента, мои модульные тесты начали попадать в базы данных, общаться с почтовыми серверами и т. д. Плохо, очень плохо.
Я знал, что я сделал неправильно, и начал думать о том, как исправить это. Следуя совету одного из постов на этой доске, я посмотрел Mockito, фреймворк для Java-моделирования, чтобы я мог покончить с использованием реальных классов DAO и почтовых серверов и просто высмеивать их функциональность.
С юнит-тестами немного под контролем, это подводит меня ко второй проблеме; зависимость от данных. Веб-сервисы, которые я разрабатывал, имеют очень мало логики, но сильно зависят от данных. В качестве примера рассмотрим один из моих компонентов:
public class PaymentScheduleRetrievalComponent implements Command {
public boolean execute(Context ctx) {
Policy policy = (Policy)ctx.get("POLICY");
List<PaymentSchedule> list = billingDAO.getPaymentStatementForPolicy(policy);
ctx.put("PAYMENT_SCHEDULE_LIST", list);
return false;
}
}
Большинство моих компонентов следуют по одному и тому же маршруту - выберите объект домена из контекста, нажмите DAO [мы используем iBatis в качестве средства отображения SQL здесь] и получите результат.
Итак, теперь вопросы:
- Как классы DAO тестируются esp, когда одна вставка или обновление могут оставить базу данных в «нестабильном» состоянии [в случаях, когда, скажем, 3 вставки в разные таблицы фактически образуют одну транзакцию]?
- Что является стандартом де-факто для функционального тестирования веб-сервисов, которые перемещают много данных, то есть бессмысленных вставок / извлечений из хранилища данных?
Ваш личный опыт / комментарии будут с благодарностью. Пожалуйста, дайте мне знать, если я пропустил некоторые детали с моей стороны, объясняя проблему.
-sasuke