Обзор

При разработке мобильных приложений мы иногда попадаем в ловушку

Я не всегда тестирую свой код, но когда я это делаю, я делаю это в рабочей среде

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

Это краткий обзор того, как мы настроили наш проект, чтобы было легко писать тесты. Наш проект имеет следующие черты

  • Использует CocoaPods
  • на основе Swift

Эти две вещи означали, что нужно было немного настроить, чтобы все работало гладко. Вот что мы сделали.

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

Какао-бобы

По умолчанию, когда вы создаете подфайл, он выглядит примерно так

target 'Circle' do 
end 
target 'CircleTests' do 
end

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

  • lib-Circle.a
  • lib-CircleTests.a

Наши тесты должны иметь доступ к модулям, определенным в Circle, для правильной компиляции. Есть несколько способов сделать это, но самый простой — определить один статический файл библиотеки, с которым будут связаны обе цели.

link_with "Circle", "CircleTests" 
pod "1PasswordExtension", "1.0.9" 
pod "AFNetworking", "2.4.1" 
...

Это создает один файл libPods.a, связанный с обеими целями. Не забудьте удалить ранее связанные библиотеки из раздела Связать двоичный файл с библиотеками в разделе Фазы сборки, чтобы не получить повторяющиеся символы/отсутствующие файлы.

Модули

Сами тесты должны иметь доступ к классам, определенным в нашей цели Circle. В Swift каждая цель — это отдельный модуль.

Это означает, что модуль Circle должен быть импортирован в каждый тестовый класс, который хочет получить доступ к тестируемому классу. Например.

import UIKit 
import XCTest 
import Circle

Также обратите внимание, что Swift вводит уровни доступа для классов/методов. Три уровня доступа:

  • Общедоступно Доступно внутри нашего модуля и за его пределами
  • Внутренний Доступен для любого класса в определяющем модуле
  • Частное Доступно только для определяющего исходного файла

По умолчанию объекты получают уровень доступа внутренний. Это означает, что классы/методы, которые мы определяем в нашем модуле Circle, не будут доступны в нашем модуле CircleTest. (Поскольку это два отдельных модуля, а внутренний модификатор доступа ограничивает доступ из другого модуля).

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

public class Money: NSObject { 
.... 
    public func isGreaterThan(otherMoney: Money) -> Bool { 
        ... 
    }

Вывод

Благодаря вышеуказанным изменениям мы смогли перейти к стандартному процессу написания тестов и их выполнения в Xcode.