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

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

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

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

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

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

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

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

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

Edit: ответ на рассматриваемое редактирование.

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

Ваше тестовое приложение - это простое приложение или сценарий, который запускает ваш графический интерфейс и затем генерирует события мыши / клавиатуры на основе входных файлов. Как я уже сказал, никогда не делал этого в 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>

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

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

Обзор специальных возможностей