Комментарии 21
Возможно есть другие, более удобные способы регулирования времени для процесса?
Немного оффтоп, т.к. не для процесса…
Но на практике, можно организовать классы/модули так, чтобы в unit-тестах просто подставлять нужное время без всяких костылей.
В теории можно в test env и для ручного тестирования похожий подход использовать.
Дело в том, что тут вся соль в тестировании алгоритмов самой вашей программы. Python от ОСи время может получать, это тестировать на мой взгляд — излишне.
Но на практике, можно организовать классы/модули так, чтобы в unit-тестах просто подставлять нужное время без всяких костылей.
Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.
Python от ОСи время может получать, это тестировать на мой взгляд — излишне.
Вот именно, что от ОСи и это надо тестировать.
В случае крупного проекта, где много фич завязано на время, это может быть оправдано. Но здесь… уж больно много мороки для в общем-то ерундовой задачи.
Этот бот в конце каждого дня отправляет (или, в зависимости от ряда условий, не отправляет) сообщение в чат и производит манипуляции с некоторыми предыдущими своими сообщениями (или, опять же, не производит).
Мне бы было этого уже достаточно. Ну ладно, хозяин-барин. Удачи!
По-моему, как раз подход с faketime лучше подходит для приемочного тестирования больших проектов, а для небольшого достаточно вынести зависимость модуля от времени как внешнюю и мокать её обычными средствами, а не системными.
Вызов условной статической System.getTime() размазан по всему коду, от чего собственно и возник вопрос у ТС.
https://dzone.com/articles/why-static-bad-and-how-avoid
http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
А то, как питон получает время от ОСи, протестировано разработчиками питона, зачем это тестировать?
Вызов условной статической System.getTime() размазан по всему коду
Специально для такого случая в питоне есть библиотека unittest.mock
Но в некоторых языках (java, C#) закрытая архитектура классов и нет манкипатчинга.
И вообще, я лично, предпочитаю mock-ам fake классы
http://www.yegor256.com/2014/09/23/built-in-fake-objects.html
Основной недостаток мока — код может сломаться, а мок это успешно скроет. Ну и вообще, магия…
Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.
Это называется не костылями, а внедрением зависимости. Может открою вам секрет, но программы можно писать вообще не разбивая их код на модули, классы, функции/процедуры. Но если разбиваешь всё-таки, то многие считают, что лучше сначала тестировать части отдельно, как можно в большей степени изолированности от окружающего мира, а уж затем приложение целиком.
Ну собственно Docker это же виртуализация приложения, то есть в основном на уровне файловой системы/библиотек, а не ОС. Поэтому по идее на уровне интуиции можно было сразу начать искать что-то библиотечное, типа faketime.
Тут надо отметить, что этот метод будет работать только если Вы получаете время через вызовы glibc. Если же у Вас в программе время получается по-другому (например, читается из procfs) или же glibc статически прилинкован к бинарнику, то трюк с LD_PRELOAD не прокатит. Попробуйте, например, протестировать так программу на go. ;)
Но поскольку у меня питоновская прога от силы строк на 400, и время там получается банально через datetime.now() — так даже удобнее. Время «обманывается», и тестировочные классы городить не надо. XD
Обманываем время: о тестировании с «подставным» временем на Linux и Docker