Мне трудно понять, как реализовать модульные тесты в классе, где все мои поля являются частными.
Класс вычисляет позицию пользователя с помощью BLE и CoreLocation - это не так важно.У меня есть протокол, который при обнаружении нового местоположения я вызываю, и все классы, которые соответствуют этому протоколу, получат идентификатор комнаты и имя комнаты.Итак, что это означает, что буквально все поля в моем классе являются частными, потому что да, нет никаких причин, по которым любой внешний класс должен иметь к ним правильный доступ?Но это также означает, что я могу буквально ничего не тестировать в этом классе, хотя есть довольно много функций, которые я хотел бы протестировать.Я имею в виду, что я мог бы просто сделать переменные внутренними, а не частными, но просто неправильно делать это только для модульного тестирования.Я слышал о внедрении зависимостей, но мне кажется, что это очень много усилий.
Например, у меня есть эта функция:
private var beacons: [AppBeacon] = []
private var serverBeacons:[Beacon] = []
private func addBeacons(serverBeacons: [Beacon]){
for beacon in serverBeacons {
let beacon = AppBeacon(id: beacon.id, uuid: beacon.uuid, building: beacon.building, name: beacon.name)
beacons.append(beacon)
}
}
я не могу проверить, был ли массив маяковна самом деле пополнил, как я хотел или нет, например.Общедоступные функции моего класса - это, в основном, функция startLocating, результатом которой являются идентификатор комнаты и ее имя, и я знаю, что при тестировании черного ящика имитируется модульное тестирование (верно?), Мне не следует беспокоиться о промежуточных шагах, но, честно говорятак много функциональности я должен просто сказать, не имеет значения?И предположим, что я заполнил маяки некоторыми значениями rssi по своему выбору, фактический алгоритм определения местоположения выполняется на сервере node.js, так что я, честно говоря, не знаю, что тестировать на стороне клиента?
Это классический MVC, и я никак не могу изменить его архитектуру до того срока, который у меня есть, так что я не знаю, как лучше отсюда пойти?Просто не проверяйте функциональность?Сделать поля внутренними, а не частными?Мы проводим тестирование самого алгоритма на стороне сервера, поэтому тестирование того, является ли идентификатор комнаты ожидаемым идентификатором комнаты, уже протестировано.
В другом посте я прочитал следующее:
«Модульное тестирование по определению - это тестирование черного ящика, что означает, что вы не заботитесь о внутренних элементах тестируемого вами модуля. В основном, вам интересно посмотреть, какой вывод получен на основе входных данных, которые вы даете ему в модульном тесте.по выводам мы можем утверждать о нескольких вещах:
- результат метода
- состояние объекта после воздействия на него,
- взаимодействиес зависимостями у объекта есть
Во всех случаях нас интересует только общедоступный интерфейс, поскольку именно он связывается с остальным миром. Личные вещи не нужныиметь модульные тесты просто потому, что любой частный элемент косвенно используется общедоступным. Хитрость заключается в том, чтобы написать достаточно тестов, которые осуществляют общедоступные элементы, чтобы частный элементОни полностью покрыты.
Кроме того, важно помнить, что модульное тестирование должно проверять спецификации модуля, а не его реализацию.Проверка деталей реализации добавляет тесную связь между кодом модульного тестирования и тестируемым кодом, что имеет большой недостаток: если детали проверенной реализации изменяются, то, вероятно, потребуется также изменить модульный тест, и это уменьшает выгоду,модульный тест для этого куска кода. "
И из-за этого я, по сути, понимаю, что я просто не должен тестировать этот модуль?