Как я могу создавать сквозные тесты для приложений Mac (Cocoa)?

Я много читал о разработке, основанном на тестах, и решил, что я хочу дать ему небольшой проект. Для справки, я в настоящее время читаю "Растущее объектно-ориентированное программное обеспечение, руководствуясь тестами".

Я понимаю, как unit test мое приложение и как unit test некоторые части пользовательского интерфейса, но я изо всех сил пытаюсь настроить сквозные тесты. Например, тестирование того, что определенный путь через все мое приложение производит правильный вывод (это мое основное понимание сквозного теста).

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

Я правильно понял, что мне нужна комбинация тестов "Логика" (тест без запуска приложения), "Приложения" (тест с запуском приложения) и асинхронные функции чего-то вроде GHUnit для выполнения этого?

EDIT:

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

  • Запустите приложение.
  • Вызовите функцию входа с учетными данными тестовых пользователей. (Примечание: не обязательно требуется автоматизация пользовательского интерфейса).
  • Убедитесь, что в окне метки указано "Вход в систему...".
  • После успешной проверки пользователя убедитесь, что на этикетке теперь написано "Добро пожаловать, Адам!".

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

Однако, возможно, я пытаюсь взять то, что читаю в "Растущем объектно-ориентированном программном обеспечении, руководствуясь тестами", и пытаюсь применить его буквально до Cocoa.

Другое UPDATE:

Итак, я читал совет до сих пор, проверял различные места, связанные с ним, и начал реализовывать что-то, все еще ссылаясь на книгу. Я думаю, что я действительно пытаюсь понять, это часть Test-Driven-Development. То, что выделялось больше всего в упомянутой книге, заключалось в том, что они описывали, что они хотели бы сделать с точки зрения пользователей сначала с приемочными испытаниями.

Я понимаю, что после того, как я начну писать методы, будет необходимо твердое модульное тестирование, но сначала я хотел написать несколько высокоприоритетных тестов, используя некоторый пользовательский интерфейс. Я начал писать свой собственный класс "драйвер", используя некоторые подобные методы для идей GHAsyncTestCase, чтобы помочь мне в этом. Звучит ли это правильно/полезно/необходимо?

Я очень ценю все комментарии до сих пор, и они определенно помогли мне разобраться в моей собственной голове, что я пытаюсь сделать и какие различные области тестирования есть. Я скоро закончу этот вопрос, так как он становится довольно большим, поэтому любой окончательный совет приветствуется!

Ответы

Ответ 1

Я думаю, что ключевым моментом, который я получил от "Growing Object Orientated Software", было как можно больше отделить от пользовательского интерфейса. Без кода, чтобы смотреть на него сложнее давать предложения, но с вашей ревизией я думаю, что отключение "проверить метку говорит..." бит из пользовательского интерфейса. Что настраивает это сообщение, и можете ли вы просто проверить это событие?

Чем больше вы можете отделить от пользовательского интерфейса, тем больше вы можете провести тестирование (быстрее и проще), чем интегрировать другие фреймворки или драйверы элементов пользовательского интерфейса.

Ответ 3

Я считаю, что вы можете использовать функции доступности для script пользовательского интерфейса. Я бы посмотрел видео WWDC 2011 на один, озаглавленный "Шаблоны проектирования для упрощения доступа к Mac". Они сделали что-то подобное в 2010 году.

Ответ 4

На основе вашего ответа на @Norman, я думаю, вы ищете рекомендации, которые охватывают как функциональные сквозные, так и конечные конечные пользователи, но, возможно, инфраструктура автоматизации пользовательского интерфейса может изменить ваш разум? Возможно, что-то навязчивое, как FoneMonkey: http://www.gorillalogic.com/fonemonkey

Если это не сработает для вас, мне было бы интересно узнать, почему и какой "пробел" вы воспринимаете в таких тестах, управляемых UI, и функциональном тестировании на основе кода?