Highstaker Apr 18 2017 at 14:49

Обманываем время: о тестировании с «подставным» временем на Linux и Docker

3 min

13K

Python*Web services testing*Development for Linux*

Tutorial

+24

Comments 21

j_wayne Apr 18 2017 at 14:58

Возможно есть другие, более удобные способы регулирования времени для процесса?

Немного оффтоп, т.к. не для процесса…
Но на практике, можно организовать классы/модули так, чтобы в unit-тестах просто подставлять нужное время без всяких костылей.
В теории можно в test env и для ручного тестирования похожий подход использовать.
Дело в том, что тут вся соль в тестировании алгоритмов самой вашей программы. Python от ОСи время может получать, это тестировать на мой взгляд — излишне.

kataklysm Apr 18 2017 at 15:58

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

Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.

Python от ОСи время может получать, это тестировать на мой взгляд — излишне.

Вот именно, что от ОСи и это надо тестировать.

Highstaker Apr 18 2017 at 16:01

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

j_wayne Apr 18 2017 at 16:09

Этот бот в конце каждого дня отправляет (или, в зависимости от ряда условий, не отправляет) сообщение в чат и производит манипуляции с некоторыми предыдущими своими сообщениями (или, опять же, не производит).

Мне бы было этого уже достаточно. Ну ладно, хозяин-барин. Удачи!

VolCh Apr 18 2017 at 18:24

По-моему, как раз подход с faketime лучше подходит для приемочного тестирования больших проектов, а для небольшого достаточно вынести зависимость модуля от времени как внешнюю и мокать её обычными средствами, а не системными.

j_wayne Apr 18 2017 at 16:07

Кому как.
Вызов условной статической 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

А то, как питон получает время от ОСи, протестировано разработчиками питона, зачем это тестировать?

batment Apr 18 2017 at 18:30

Вызов условной статической System.getTime() размазан по всему коду

Специально для такого случая в питоне есть библиотека unittest.mock

j_wayne Apr 18 2017 at 18:34

Да, и в руби есть timecop, он еще удобнее, чем универсальный мокинг, я его использую.
Но в некоторых языках (java, C#) закрытая архитектура классов и нет манкипатчинга.
И вообще, я лично, предпочитаю mock-ам fake классы

http://www.yegor256.com/2014/09/23/built-in-fake-objects.html

Основной недостаток мока — код может сломаться, а мок это успешно скроет. Ну и вообще, магия…

VolCh Apr 18 2017 at 18:20

Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.

Это называется не костылями, а внедрением зависимости. Может открою вам секрет, но программы можно писать вообще не разбивая их код на модули, классы, функции/процедуры. Но если разбиваешь всё-таки, то многие считают, что лучше сначала тестировать части отдельно, как можно в большей степени изолированности от окружающего мира, а уж затем приложение целиком.

f9k56 Apr 18 2017 at 16:32

Круто. Интересно на винде для приложений есть такая фича.

ushliy Apr 18 2017 at 21:57

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

f9k56 Apr 19 2017 at 16:16

Спасибо. Видимо у товарища и у меня похожие интересы.)

jetu Apr 18 2017 at 16:32

Спасибо за статью, как раз нужно было «поиграться» с системным временем.

velvetcat Apr 18 2017 at 17:59

> Возможно есть другие, более удобные способы регулирования времени

Да, есть один очень хороший способ — не завязываться намертво на недетерминированные неконтролируемые зависимости, и больше не пытаться исправить то, что исправлять не следует.

j_wayne выше все правильно сказал.

saboteur_kiev Apr 18 2017 at 19:11

«Похоже, что Docker не настолько глубоко производит виртуализацию, как мне казалось.»

Ну собственно Docker это же виртуализация приложения, то есть в основном на уровне файловой системы/библиотек, а не ОС. Поэтому по идее на уровне интуиции можно было сразу начать искать что-то библиотечное, типа faketime.

VolCh Apr 18 2017 at 19:32

Собственно Docker вообще не виртуализация, а изоляция процесса в контейнере от процессов вне его.

crazylh Apr 18 2017 at 22:10

Мы для таких целей используем datefudge

afunix Apr 19 2017 at 05:37

А как же модульная архитектура, mock-и, stub-ы, фабрики и все то, что изобрело человечество на данный момент в области computer science?

Rast1234 Apr 19 2017 at 12:50

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

madkite Apr 19 2017 at 13:36

Тут надо отметить, что этот метод будет работать только если Вы получаете время через вызовы glibc. Если же у Вас в программе время получается по-другому (например, читается из procfs) или же glibc статически прилинкован к бинарнику, то трюк с LD_PRELOAD не прокатит. Попробуйте, например, протестировать так программу на go. ;)

Highstaker Apr 19 2017 at 14:25

Кстати это, как и многие другие ограничения, описано в пункте 2 их README. В таких случаях без mock'ов не обойтись (не уверен насчёт datefudge, не пробовал).

Но поскольку у меня питоновская прога от силы строк на 400, и время там получается банально через datetime.now() — так даже удобнее. Время «обманывается», и тестировочные классы городить не надо. XD

Show the best of all time