Какой у вас подход к тестированию приложений для iPhone / iPad?

Question

При разработке для iPhone / iPad вы

1. Проводится ли тестирование модуля / интеграции / и т. Д.?
2. Какие рамки вы используете?
3. Какие еще фреймворки (ы) вы пробовали (если решили не использовать их, почему бы и нет?)

---

ПРИМЕЧАНИЕ Это основано на вопросе, заданном несколько дней назад (который с тех пор сильно редактировался). Вопрос вызвал некоторые интересные ответы, которые могут быть полезны для объединения в одном месте.

Answer 1

Вот мой текущий подход к тестированию перед отправкой приложения.

1) Сборка и анализ с использованием встроенного в Xcode анализатора Clang.

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

2) Тщательно проверьте все предупреждения. Некоторые из них могут быть действительно вредными. Уберите предупреждения, где это возможно.

3) Используйте инструменты для проверки утечек памяти, объема памяти во время выполнения и т. Д.

4) Используйте Shark для выявления проблем с производительностью, когда я чувствую, что это необходимо.

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

6) Отправьте специальную версию приложения альфа-тестерам, исправьте обнаруженные ошибки, затем снова отправьте приложение как альфа-, так и бета-тестерам и сообщите о исправленных ошибках.

7) Финальный тест, проведенный лично на разных устройствах, на данный момент iPhone 3GS, iPhone 3G и iPod Touch.

Answer 2

Лично я делаю только юнит-тестирование классов и / или методов, которое имеет смысл для юнит-тестирования и стоит затраченных усилий. По моему мнению, это сводится к следующим типам кода:

• Чистые вычислительные алгоритмы
• Анализатор данных различного рода (файлы, данные в Интернете и т. Д.)
• Методы, имеющие отношение ввода / вывода
• И, наверное, еще один или два, о которых я забыл.

Я редко использую unit-тестирование для тестирования кода, связанного с GUI.

До сих пор я использовал только фреймворк OCUnit / SenTesting, поставляемый с iPhone.

Я также обнаружил, что составление краткого контрольного списка того, что нужно сделать в процессе выпуска, требует значительного тестирования. Проблемы с продуктом часто возникают не из-за непосредственного тестирования, а из-за небольших (забытых) шагов в процессе сборки / выпуска.

Answer 3

1. Нет
2. N / A
3. N / A

Честно говоря, я обнаружил, что объем работы, необходимой для создания одиночного модульного теста, является полной болью. Существует тонна насмешек, которые требуются даже для самых простых тестов. Кроме того, было трудно разделить модели, представления и контроллеры в iPhone. И учитывая, что мое приложение было довольно маленьким, оно не стоило времени.

Если бы / когда я писал что-то большее, я бы снова пересмотрел модульное тестирование.

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

Answer 4

Единственное тестирование проводится с прикладными инструментами, и только иногда.

Answer 5

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