Как вы тестируете свои графические интерфейсы Cocoa?

Это зависит от того, что вы подразумеваете под «тестированием графического интерфейса Cocoa».

Если вам нужны такие инструменты, как старый инструмент Virtual User включен в MPW, тогда их немного; вы будете использовать такие инструменты, как Squish и Eggplant.

Если вы хотите написать модульные тесты для человеческого интерфейса вашего приложения, я предлагаю вам следовать "доверяй, но проверяй", при котором вы доверяете тому, что, пока вы устанавливаете правильные связи (в соответствии с вашей структурой), ваши пользователь может правильно взаимодействовать с вашей структурой. Это означает, что вы можете выполнить большую часть тестирования, проверив, что ваша модель и код контроллера правильно подключены к вашим представлениям.

В своем блоге я написал пару примеров того, как это сделать конкретно с Cocoa, один для тестирование пользовательских интерфейсов, созданных с помощью target-action, и один для тестирование пользовательских интерфейсов, созданных с помощью привязок Cocoa. (Помните, конечно, что эти две технологии не исключают друг друга: если вы хотите выполнять перетаскивание в табличном представлении, управляемом с помощью привязок Cocoa, у вас также будет источник данных и, возможно, делегат, подключенный через целевое действие. .)

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

Чего я практически никогда не делаю, так это пишу код для «симуляции событий». Самое близкое, к чему я когда-либо приходил, - это создание поддельного информационного объекта перетаскивания и передача его в источник данных представления схемы, чтобы убедиться, что он будет правильно обрабатывать перетаскивания.

Я бы посоветовал вам взглянуть на Toolbox для Macintosh от Google. Он имеет, помимо некоторых других приятных вещей, очень хороший набор дополнений для тестов состояния и рендеринга для NSView и CALayers. В своих модульных тестах вы утверждаете, что состояние представления/слоя или отображаемое изображение соответствует сохраненному (по имени) шаблону. Если шаблон отсутствует в тестовом пакете или не соответствует сохраненной версии, для проверки создается новое закодированное состояние или обработанный TIFF. GTM предоставляет категории для NSView и CALayer для кодирования и рендеринга состояния. Очевидно, вы можете переопределить эти категории в своих собственных подклассах NSView или CALayer для кодирования соответствующего состояния (используя протокол NSCoder) или рендеринга.

Он также позволяет (легко) программно отправлять ключевые события и запускать цикл выполнения с помощью модульных тестов и поддерживает модульное тестирование как на OS X, так и на iPhone.

Я создал пакет Python с открытым исходным кодом, который использует Apple Accessibility API, среди прочего, для создания классической библиотеки автоматизации графического интерфейса, предоставляя вам возможность просмотра и взаимодействия с графическими интерфейсами Cocoa. домашняя страница PyATOM

Вы можете проверить и рассмотреть возможность использования Eggplant от TestPlant (официально Redstone Software) по адресу http://www.testplant.com/.

Вот статья, которую Apple опубликовала на них в прошлом году.

В последнем подкасте CocoaCast есть интервью с Яном Дисом, автором «Scripted GUI Testing with Ruby». Дополнительную информацию можно найти на странице CocoaCast.