Интерфейсы на границе между формами и фасадами также стали идеальным местом для изоляции объектов для модульного тестирования.
Чтобы протестировать некоторую форму, модульный тест создает фиктивный объект, который реализует интерфейс фасада. Тест приказывает фиктивному объекту передавать данные форме с некоторыми ожидаемыми результатами, включая условия ошибок, которые было бы очень трудно воспроизвести с реальным фасадом. Пожалуй, мы все рассматривали фиктивные объекты как двусторонний компромисс: хотя они обеспечивали возможность модульного тестирования, такая тесная привязка тестов к реализации форм все же вызывала беспокойство. Например, для фиктивных объектов приходилось задавать точную последовательность вызовов методов и точные значения параметров (более современные инфраструктуры обладают большей гибкостью). В результате с изменением внутренней структуры форм тесты переставали работать, хотя внешнее поведение при этом оставалось неизменным. В определенной степени это та цена, которую приходится платить за использование фиктивных объектов.
Во всех приложениях Creation Center (как студийных, так и в приложениях центра печати) использовался один и тот же стек уровней. Лишив GUI руководящей роли, мы избавились от бесконечной возни с настройками Swing. Инверсия управления также определила единую структуру, которой могло следовать каждое приложение. Хотя архитектура выходила за рамки обычного «трехслойного пирога», наш стек обеспечивал достаточно эффективное разделение сфер влияния: использование Swing ограничивалось областью UI, взаимодействие с предметной областью – формами, а долгосрочное хранение данных – фасадами.
Related posts: