Тут случился значительный запил эмулятора CLI утилиты тындекса yandex-disk:
https://github.com/slytomcat/yandex-disk-simulatorЧем был сподвигнут: CircleCI (который я прикручивал к части своих поделок на GO, включая
го-шную обертку утилиты yandex-disk, для го-шных же версий индикатора под
GTK и
QT) перешел с виртуалок на контейнеры (что вполне в духе современных трендов в технологиях). И все бы ничего, но их годные образы для GOLANG построены на на основе debian.
Уж не знаю что там не так в образах, но команда создания токена (yandex-disk token) просто крашится в этих образах...
И можно было бы покопать, и наверняка решить эту проблему, но мне подумалось, а почему это мне обязательно делать интеграционные тесты обертки с использованием оригинальной утилиты да еще с подсовыванием туда (через переменные CircleCI) реальные имя и пароль для доступа к специальному тестовому акаунту на тындекс-диске?!
Подумал я и решил что ведь не так и трудно эмулировать работу утилиты, т.е. сделать аля mock-сервис, и тестировать либу на этом эмуляторе.
Чем хорош подход аля-mock:
1. всегда стабильные, предсказуемые реакции.
2. отсутствие необходимости в реальном аккаунте на тындекс.диске
3. возможность рулить реакциями эмулятора из кода тестов (по сути когда вы в тестах используете свой же эмулятор вы получаете замкнутый контур тестирования, когда тестирующий код и подконтрольный эмулятор работают по обоим сторонам тестируемой библиотеки/сервиса)
Чем плох такой подход:
1. довольно трудно полностью повторить все возможные реакции чужой утилиты (с закрытым кодом, т.е. по сути - черный ящик)
2. нужно внимательно отслеживать изменения в черном ящике что бы менять эмулятор в соответствии с изменениями в нем.
Первый недостаток достаточно не значителен т.к. обертка использует очень ограниченный набор команд утилиты и довольно грубо обрабатывает результаты, которые выдает утилита (выхлоп в stdout/stderr и exit code). Так что эмулировать можно не слишком детально и не все.
А вот со второй проблемой бороться довольно трудно. Но это можно автоматизировать: смысл простой - берем некий логгер и логгируем реакции "живой" утилиты тындекса (не обязательно все возможные а только основные которые эмулируются), и запоминаем его. После обновления демона снимаем лог утилитой повторно и смотрим - есть ли разница. Если все совпало (с точностью до небольших расхождений во времени) то забиваем, иначе правим эмулятор.
Но пока это идеи на будущее. А пока удалось наконец провести
полное и успешное тестирование обертки с эмулятором через CircleCI 
.
Пользователь добавил сообщение 23 Декабря 2018, 22:01:02:
Сами тесты конечно тоже пришлось править. Но там правки преимущественно в сторону упрощения.
Чуть поломал голову про тестирование на машине где уже установлен настоящий yandex-disk. Ведь для тестов важно подпихнуть эмулятор с оригинальным именем вместо оригинальной утилиты. Но в принципе тут все просто - подсовываем эмулятор (с именем оригинала) в путь, который добавляем в начало PATH и в тестовом окружении будет использоваться именно эмулятор. Но тестирование на машине с дефолтными настройками все равно требует дополнительных манипуляций... хотч есть мысли как это можно обойти (идеи на развитие эмулятора).
Тема: Плагины/индикаторы для индикации статуса синхронизации с Yandex-disk (Прочитано 936153 раз)
