При разработке для iPhone/iPad вы
ПРИМЕЧАНИЕ Это основано на вопросе заданном несколько дней назад (с тех пор он был сильно отредактирован). Вопрос вызвал некоторые интересные ответы, которые могут быть полезны для агрегирования в одном месте.
Вот мой текущий подход к тестированию перед отправкой приложения.
1) Постройте и проанализируйте с помощью интегрированного анализатора Clang Xcode.
Это полезно во многих отношениях, оно ловит много глупых вещей, а также некоторые утечки памяти (хотя иногда его результаты содержат ложные срабатывания).
2) Проверьте все предупреждения. Некоторые из них могут быть действительно вредными. Удалите предупреждения, если это возможно.
3) Используйте инструменты для проверки утечек памяти, объема памяти во время выполнения и т.д.
4) Используйте Shark для определения проблем с производительностью, когда я чувствую, что это необходимо.
5) Выполните (вручную) все предопределенные серии тестов, чтобы проверить, что как пользовательский интерфейс, так и базовый код работают должным образом. При добавлении новых функций в приложение всегда выполняйте регрессионные тесты, чтобы гарантировать, что все выполняется гладко и правильно. Я отбросил модульные тесты давно, из-за невероятного количества времени, необходимого для их настройки и запуска.
6) Отправляйте специальную версию приложения для альфа-тестеров, исправляйте ошибки, а затем отправляйте приложение снова как альфа-, так и бета-тестерам и исправляйте ошибки.
7) Окончательный тест, выполненный лично на разных устройствах, на данный момент iPhone 3GS, iPhone 3G и iPod Touch.
Лично я делаю только модульное тестирование классов и/или методов, которые имеют смысл для unit test и стоят усилий. В моем oppinion это сводится к следующим типам кода:
Я редко использую модульное тестирование для проверки кода, связанного с GUI.
Я использовал инфраструктуру OCUnit/SenTesting, поставляемую с iPhone до сих пор.
Я также обнаружил, что составление краткого контрольного списка вещей, которые нужно сделать в рамках процесса выпуска, составляет много испытаний. Часто это не относится к материалам, связанным с прямым тестированием, которые создают проблемы в продукте, а также небольшие (забытые) шаги в процессе сборки/выпуска.
Честно говоря, я нашел объем работы, необходимый для создания единственной unit test, чтобы быть полной болью. Там тонна издевательств, требуемая даже для самых простых тестов. Кроме того, было трудно отделить модели, представления и контроллеры от iPhone. И учитывая, что мое приложение было довольно маленьким, это не стоило времени.
Если/Когда я писал что-то большее, я бы снова исследовал модульное тестирование.
С учетом сказанного я провел тонну тестирования стиля пользователя /QA. Наблюдая за тем, как другие используют приложение (действительно полезно!), Я использую приложение и т.д. Вы не можете сэкономить там, если вы скупитесь на модульные тесты!
Я провел тестирование модулей в своих приложениях. Но так как мой калькулятор легче unit test против других более сложных приложений. Я нахожу его эпическим полезным, когда я нахожу случай, который не работает правильно (обычно из ручного тестирования), затем я пишу тест, чтобы (надеюсь, неясный) случай всегда будет проверяться в будущем. Таким образом, я не повторяю ошибки дальше по строке.
Единственное тестирование - это приложение с инструментами, и это только иногда.