Отдельная схема для теста производительности в xcode - PullRequest
0 голосов
/ 06 ноября 2018

Есть ли какое-либо преимущество в создании отдельного Performance Test scheme в Xcode (аналогично схемам, подобным Unit Test и UI Test), за исключением того факта, что тестируемый код более сегрегирован? Стоит ли хранить 3 схемы тестирования для одного проекта XCode?

Что я хотел сказать, так это то, что даже если я напишу все свои тесты производительности в блоке self.measure{ } в одном и том же комплекте (схеме) модульных тестов, это будет иметь какое-то значение, когда проект будет расти и подвергаться непрерывной интеграции в Дженкинс?

Каков промышленный стандарт реализации Performance testing in Xcode? Все ли тестирование производительности проводят в одном и том же модульном тесте? Почему и почему нет?

1 Ответ

0 голосов
/ 06 ноября 2018

Прежде всего, обратите внимание, что схема и цель не одно и то же:

A target указывает продукт для сборки и содержит инструкции для сборки продукта из набора файлов в проекте или рабочей области.

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

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

(Выделение мое). Вот хитрость и ответ на ваш вопрос: для тестов производительности особенно важно иметь специальную схему для их запуска, потому что это позволяет вам создавать приложение с другой конфигурацией сборки. И вы хотите это сделать, потому что вы хотите скомпилировать свое приложение в режиме выпуска, чтобы ваши тесты производительности выполнялись на оптимизированной сборке . Схема с приложением, встроенным в конкретную конфигурацию сборки

Если быть точным, для тестов производительности вам нужно добавить новую конфигурацию сборки, аналогичную Release, но с включенным флагом сборки «Enable Testability». Это «Включить тестируемость» необходимо, чтобы тесты связывались с вашим приложением. Таким образом, в вашем проекте у вас будет 3 конфигурации сборки: Release, Debug и PerformanceTests.

3 образа конфигурации сборки

Включить тестируемое изображение

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

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

Вы можете увидеть все это в действии в проекте SwiftGraph . В частности, это было реализовано в this commit

...