Как я могу написать автоматический тестовый модуль GUI в XCode?

Question

Я хочу написать модульное тестирование только части GUI моего приложения Cocoa.

В модульном тестировании учебника есть тестовая структура и тестовый пример, который вызывает тестируемый модуль. Весь код ниже этого блока вычеркнут. Таким образом, и вход и выход контролируются и контролируются; проверяется только код в тестируемом устройстве.

Я хочу сделать то же самое, когда тестируемый модуль - это мой графический интерфейс:
1) Установите какую-то платформу, где я могу написать код, который будет манипулировать и проверять элементы управления графическим интерфейсом.
2) Подключите мои элементы управления GUI к макетам моего реального кода, а не к реальным экземплярам.
3) Запустите тест, который манипулирует элементами управления, а затем проверяет фиктивный объект, чтобы увидеть, были ли вызваны правильные методы с правильными параметрами, и проверяет графический интерфейс, чтобы увидеть, вызывают ли ответы от фиктивного объекта правильные изменения в виджетах. 1008 *

Кто-нибудь делает это? Если так, то как? Любые идеи о том, как я мог это сделать?

Спасибо

Pat

(Правка) Чтобы привести очень конкретный пример, я хочу:
1) Напишите тестовый пример, который выберет пункт меню «MyMenu» -> «MyItem». В этом тестовом примере я хочу проверить, чтобы метод [AppDelegate doMyItem] вызывался точно один раз, и чтобы никакие другие методы в AppDelegate не вызывались.
2) Создайте макет объекта AppDelegate. (Я знаю как это сделать)
3) Каким-то образом (рукопожатие здесь) связать мое приложение так, чтобы вместо реального использовался фиктивный экземпляр AppDelegate.
4) Запустите тест. Смотреть не получится, потому что 1) Я еще не создал MyMenu. 2) Я еще не создал MyItem. 3) Я не выполнил работу IB по подключению MyItem к [AppDelegate doMyItem], или 4) потому что я еще не написал метод doMyItem.
5) Исправьте вышеуказанные четыре вопроса (по одному, если я чувствую себя действительно педантичным в тот день).
6) Запустите тест еще раз и посмотрите, как он пройдет.

Это проясняет вопрос?

Answer 1

Два принципа, две ссылки:

• Сделайте вид настолько тупым, насколько это возможно, с помощью пассивного представления : это облегчает тестирование графического интерфейса
• Доверяй, но проверяй : Доверяй какао реализацию кнопок, меню, ... Но проверь, что цель и действие правильно связаны, что привязки ожидается.

Answer 2

Вы изучили структуру доступности? Это должно позволить одному приложению проверять пользовательский интерфейс другого приложения и генерировать пользовательские события взаимодействия.

Обзор доступности

Answer 3

Вот несколько популярных способов сделать это в целом (должно работать с большинством, если не со всеми совместимыми с какао языками).

1 - создать интерфейс обратного вызова. Одним из входных данных при создании элементов GUI является реализация этого интерфейса. При взаимодействии с пользователем элемент GUI вызывает функцию обновления для этого интерфейса. Реальная реализация и тестовая реализация.

2 - Использовать обработчики событий. Зарегистрируйте все элементы GUI с помощью одного или нескольких обработчиков событий, и пусть GUI генерирует события при взаимодействии с пользователем. Имейте интерфейс обработчика событий с двумя реализациями, снова один для реального использования и один для тестирования.

Редактировать: упс, пропущено требование № 1. Никогда не делали этого с особыми элементами управления OSX, но в целом есть два подхода.

1 - создать скрипт или приложение, которое генерирует пользовательский ввод. Недостатком является то, что на самом деле не так просто проверить графический интерфейс. Вместо этого вам нужно сгенерировать хорошие контрольные примеры, чтобы убедиться, что все, что должно быть, есть и ничего лишнего.

2 - создать интерфейс с тестовой реализацией, заменяющий уровень рендеринга и интерфейса. Это проще с библиотеками, такими как SDL или directFB, и меньше с такими вещами, как OSX API, win32 API и т. Д.

Редактировать: ответ на редактирование в вопросе.

В случае вашего примера, используя отдельное приложение для тестирования и обработчики событий, вот как это будет выглядеть:

Ваше тестовое приложение - это простое приложение или скрипт, который запускает ваш графический интерфейс, а затем генерирует события мыши / клавиатуры на основе входных файлов. Как я уже сказал, никогда не делал этого в OSX (только QNX). Если вам повезет, вы сможете генерировать события мыши и клавиатуры с помощью API, но вам придется спросить кого-то еще, если это возможно.

Итак, создайте вход для вашего теста. Тестовое приложение проанализирует это, чтобы узнать, что делать. Это может быть простой XML, подобный этому:

<testcase name="blah"><mouseevent x="120" y="175" type="click"/></testcase>

или любой другой последовательности мыши.

Когда ваш скрипт выполняет эту команду, он щелкает мышью по этой кнопке. Ваш обработчик событий поймет это. Но теперь вы должны запустить ваше приложение с флагом --test или что-то подобное, чтобы оно на самом деле использовало обработчик тестовых событий. Вместо того, чтобы делать то, что обычно делает ваше приложение, обработчик тестовых событий может выполнять некоторые пользовательские действия. Например, он может выполнять некоторые из обычных действий (вам все еще нужен графический интерфейс для ответа), а затем отправлять сообщение (через сокет, по каналу и т. Д.) В ваше тестовое приложение.

Ваше тестовое приложение получит это сообщение и сравнит его с тем, что оно ожидает увидеть. Так что теперь, возможно, ваш тестовый XML выглядит так:

<testcase name="blah">
   <mouseevent x="120" y="175" type="click"/>
   <response>doMyItem() called</response>
</testcase>

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