Единичное тестирование - замечательно, но

Я потратил время на создание некоторых тестов Unit и установил цели в XCode и т.д., и они очень полезны для нескольких классов. Однако:

Я хочу протестировать небольшие части пользовательского интерфейса, для которых я не хочу запускать все приложение. Нет понятия pass/fail: мне нужно "видеть" фрагменты, а я может сделать фиктивные экземпляры всех соответствующих классов для этого. Мой вопрос: как я могу установить это в XCode?

Я понимаю, что я мог бы использовать другой проект XCode для каждого класса (или групп классов), но это кажется немного громоздким. Еще одна цель для каждого?

ОТВЕТЫ

Ответ 1

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

Если вы все еще настаиваете на использовании модульных тестов, вы можете показать свой графический интерфейс в течение некоторого периода времени, например, 10 секунд. Таким образом, тестовый сценарий будет работать до тех пор, пока графический интерфейс не будет закрыт или тайм-аут не истечет, и каждый тест будет занимать до N секунд для выполнения.

Ответ 2

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

Этот инструмент позволяет вам использовать сценарии Javascript для интерактивного тестирования интерфейса вашего приложения, и это происходит таким образом, что не требует проверки точных значений пикселей или позиций на экране. Он использует встроенные в систему ловушки доступности для VoiceOver для идентификации и взаимодействия с компонентами.

Используя этот инструмент, я смог написать сценарий тестов, которые полностью выполняют мое приложение как пользователь, взаимодействующий с ним, а также тесты, которые воздействуют на определенные области и ищут тонкие накопления памяти.

Документация по этой части Инструментов немного скудна, но недавно я преподавал урок, посвященный теме, по которой видео бесплатно доступно в iTunes U (ищите класс Тестирование в осеннем семестре). Мои заметки о курсе (в формате VoodooPad) также охватывают это. Я также настоятельно рекомендую посмотреть видео сессию WWDC 2010 306 - "Автоматизация тестирования пользовательского интерфейса с помощью приборов".

Ответ 3

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

Ответ 4

Я бы взял двухуровневый подход к UI "модульному тестированию":

  • lthough Cocoa/CocoaTouch все еще ближе к Model-View-Controller, чем парадигма Model-View-ViewModel, вы можете получить большую часть возможностей тестирования, разбив ваш "Вид" на "модель представления" "и" презентатор "(обратите внимание, что это несколько похоже на пару NSView/NSCell, у инженеров Cocoa это было давно). Если представление представляет собой простой уровень представления, чем вы можете проверить поведение представления с помощью модуля, проверяющего "модель представления".

  • Чтобы протестировать чертеж/рендеринг ваших представлений, вам придется либо провести тестирование на людях, либо выполнить рендеринг/пиксельные тесты. Google Toolbox для Mac имеет несколько инструментов для выполнения поэтапного сравнения отображаемых NSViews, CALayers, UIViews и т.д. Я написал a для проекта Core Plot, чтобы справиться с ошибками тестирования и слить файлы ссылок обратно в ваш пакет unit test немного легче.