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

Question

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

Еще одно ОБНОВЛЕНИЕ:

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

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

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

Answer 1

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

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

Answer 2

Вас может заинтересовать каркас Square KIF: http://corner.squareup.com/2011/07/ios-integration-testing.html

Это выглядит действительно круто для интеграции / тестирования пользовательского интерфейса.

Answer 3

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

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

Answer 4

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