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

Question

Я потратил время на настройку некоторых модульных тестов и установки целей в XCode и т. Д., И они довольно полезны для нескольких классов.Тем не менее:

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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