Как протестировать UIViewControllers во время изготовления?
Я - крупный сторонник тестирования, но не очень хороший практик. Я сделал вполне прилично при получении покрытия на моих объектах модели и программировании их в стиле TDD. Я на самом деле наслаждаюсь им так, я хотел бы расширить это до своего слоя контроллера, особенно мой UIViewController подклассы.
К сожалению, много классов UIKit не функционируют в независимых тестах. Однако я недоволен ограничением только запущения моих зависимых тестов на устройстве. Для меня действительно важно выполнить все модульные тесты перед каждой сборкой, и это кажется мне как его возможное и стоящее к модульному тесту (в противоположность другим типам тестирования) кодом контроллера.
Мой вопрос - просто это: Как я тестирую UIViewControllers таким способом, который тестовый прогон перед каждой сборкой? Я знаю о нескольких различных решениях этой проблемы, но не знаю много о различных преимуществах каждого.
3 ответа
Так что я был недоволен сложившейся ситуацией, и ответы Даниэля и Эда побудили меня продолжать улучшать ситуацию. Я решил взять дело в свои руки.
В итоге я написал небольшое приложение Cocoa Touch, которое в -applicationDidFinishLaunching сканирует иерархию классов на предмет любых подклассов SenTestCase и запускает их. В отличие от материала для модульного тестирования GoogleToolboxForMac, я попытался использовать как можно больше встроенного оборудования SenTesting, и в результате у меня не получилось так много кода. Я не проводил слишком много тестирования, кроме проверки того, что UILabel выделяет без сбоя тестовой установки (otest на самом деле дает сбой, если вы попытаетесь), но он должен работать.
В общем, если вы столкнулись с проблемой среды, из-за которой безусловное тестирование кажется невозможным, вы можете обойти ее, если преимущества достаточно велики, чтобы оправдать некоторые трудности.
Ситуация здесь является частным случаем нежелательных внешних зависимостей, которые я обычно решаю в своих модульных тестах, либо #ifdefdefing крошечные биты зависимого кода, либо реализуя классы-заглушки для заполнения ожидаемых ролей зависимостей в достаточном количестве, чтобы мой код мог быть проверенным.
Таким образом, в этом конкретном случае вы можете создать новый исходный файл, связанный только в тестовом пакете, под названием «UIKitStubClasses.m»… внутри него вы можете реализовать самое необходимое для имитации зависимых от UIKit классов, таких как UIViewController, чтобы ваши тесты связываются и тщательно проверяют свою логику.
Важно помнить, что обычно это не так уж и много работы. Тесты сообщат вам, что вам нужно реализовать в заглушке, например, путем выдачи исключений для нереализованных методов. Вы просто добавляете то, что вам нужно, чтобы заглушить ошибки и протестировать свой код, и тогда вашего класса-заглушки будет достаточно для тестирования , как и любого из допустимых классов системной инфраструктуры.
Разве вы не можете использовать советы / методы из блога Криса Хэнсона здесь: http://chanson.livejournal.com/120263.html
Кажется, что вам, вероятно, потребуется запустить приложение в качестве тестовой среды, но это вполне выполнимо. Тот факт, что вы запускаете «приложение», не означает, что оно обязательно должно выполнять обычные действия вашего приложения. В качестве альтернативы вы можете создать другую цель приложения, которая представляет собой простое фиктивное приложение, которое будет загружать ваши тестовые пакеты и запускать их.
Я согласен, что это может быть не идеально, но похоже, что это может сработать, и похоже, что это можно автоматизировать.