Тесты устойчивые ко времени выполнения
От: Pek2014 Россия  
Дата: 22.02.17 13:50
Оценка:
Добрый день, коллеги. Поделитесь опытом, pls.

Как вы делаете тесты устойчивые ко времени выполнения теста.
... как вы поступаете, если результат работы тестируемой процедуры зависит
от времени проведения теста (т.е. внутри процедуры в С# делается DateTime.Now
или в SQL делается GETDATE()). Как вы обеспечиваете, что при всё время разных
результатах тесты работают.

Есть какой-то общепринятый единый подход?

Мнение: Писать довольно сложные ассерты, которые проверяют не изменилось все,
что не зависит от времени, и изменилось и правильным образом всё то, что от
времени зависит — это жутко хлопотно. Нельзя ли "остановить время" и
писать тест, как будто время не течёт совсем? Это сильно упростило бы жизнь.
Можно было бы просто сравнивать целиком "мгновенные снимки" состояний.

Как поступаете вы?
Re: Тесты устойчивые ко времени выполнения
От: Sshur Россия http://shurygin-sergey.livejournal.com
Дата: 22.02.17 14:12
Оценка: 16 (1) +1
Здравствуйте, Pek2014, Вы писали:

P>Добрый день, коллеги. Поделитесь опытом, pls.


P>Как вы делаете тесты устойчивые ко времени выполнения теста.


P>Как поступаете вы?


Очевидно, вынести часть, отвечающую за получение текущего времени и задержки в отдельный компонент и замОчить его
Шурыгин Сергей

"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re[2]: Тесты устойчивые ко времени выполнения
От: Pek2014 Россия  
Дата: 22.02.17 14:48
Оценка:
Здравствуйте, Sshur, Вы писали:

P>>Как вы делаете тесты устойчивые ко времени выполнения теста.

S>Очевидно, вынести часть, отвечающую за получение текущего времени и задержки в отдельный компонент и замОчить его

Хочу уточнить: вы САМИ так делаете? Или вы это чисто теоретически?
Ведь этим компонентом должны пользоваться все, кому нужно текущее время.
Это должно быть решение на уровне всего проекта, централизовано?
Отредактировано 22.02.2017 14:53 Pek2014 . Предыдущая версия .
Re: Тесты устойчивые ко времени выполнения
От: fddima  
Дата: 22.02.17 14:53
Оценка: +1
Здравствуйте, Pek2014, Вы писали:

P>Как поступаете вы?

Не использую DateTime.Now или GETDATE() в BL/процедурах, или стараюсь избегать. Для тестов — внешний/тестовый источник времени задающий например некий оффсет.
Но в моей практике — эти даты/время хоть и были "сейчас" — но они всё равно являлись параметром транзакций BL. Более того — стоит определится — "сейчас" — это когда? Постановка запроса в очередь, начало его обработки и прочее. Должна ли соблюдаться консистентность этого времени на разных этапах обработки запроса. Ну т.е. например за один запрос выполняется DateTime.Now, GETDATE() и ещё один раз DateTime.Now. Так вот — 3 разных значения — и не всегда отличаются они только миллисекундами.
Re[3]: Тесты устойчивые ко времени выполнения
От: fmiracle  
Дата: 22.02.17 15:01
Оценка:
Здравствуйте, Pek2014, Вы писали:

P>Хочу уточнить: вы САМИ так делаете? Или вы это чисто теоретически?

P>Ведь этим компонентом должны пользоваться все, кому нужно текущее время.
P>Это должно быть решение на уровне всего проекта, централизовано?

Ну да. Для C# совсем не сложно реализовать TimeService и с методом GetCurrentDateTime() и следить чтобы все по проекту его использовали. Ну собственно если человек будет писать юнит-тесты у него сразу возникнет вопрос "как же сверить что дата была проставлена текущая?", а ответ уже есть.
Re[4]: Тесты устойчивые ко времени выполнения
От: Pek2014 Россия  
Дата: 22.02.17 15:13
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, Pek2014, Вы писали:


P>>Хочу уточнить: вы САМИ так делаете? Или вы это чисто теоретически?

P>>Ведь этим компонентом должны пользоваться все, кому нужно текущее время.
P>>Это должно быть решение на уровне всего проекта, централизовано?

F>Ну да. Для C# совсем не сложно реализовать TimeService и с методом GetCurrentDateTime() и следить чтобы все по проекту его использовали. Ну собственно если человек будет писать юнит-тесты у него сразу возникнет вопрос "как же сверить что дата была проставлена текущая?", а ответ уже есть.


Понятно. Спасибо.
А если у вас нет возможности повлиять на проект в целом?
Re[2]: Тесты устойчивые ко времени выполнения
От: Pek2014 Россия  
Дата: 22.02.17 15:19
Оценка:
Здравствуйте, fddima, Вы писали:

P>>Как поступаете вы?

F> Не использую DateTime.Now или GETDATE() в BL/процедурах, или стараюсь избегать.

Попробую собрать все возможные решения.

Способ 1. Следить (обязать, ввести правило), чтобы не было "тайного"
использования текущего времени. Тем процедурам, результат которых зависит от
текущего времени, надо это время передавать явно как параметр. Тогда при
тестировании у нас будет возможность передавать время как параметр и
значит результат теста станет фиксированным.

Способ 2. Делать единый источник текущего времени и времени. Всех обязать
использовать только этот компонент для получения текущего времени.
Компонент замОчить и так управлять временем и значит результат теста станет
фиксированным.

Способ 3. В тестах писать такие ассерты, которые учитывают то, что некоторые
результаты должны изменяться и правильным образом коррелировать с текущим временем,
а другие должны быть фиксированны.

Способ 4. Исполнять тесты на серваке (виртуалке), на котором принудительно
установлено системное время.

Если вы не можете решать за весь проект в целом, вам остаются только два последних способа.
Так?
Re: Тесты устойчивые ко времени выполнения
От: andrey.desman  
Дата: 22.02.17 15:50
Оценка:
Здравствуйте, Pek2014, Вы писали:

P>Есть какой-то общепринятый единый подход?

P>Как поступаете вы?

Все, что должно тестроваться, пишется как чистые функции / классы / методы. Но это с самого начала делать надо, конечно.
Уже написанный грязный код по-немногу разбивается на грязную составляющую и чистую. Тестируется только чистая, разумеется. Но это порой очень тяжко, особенно если грязных функций в коллстэке дофига.
Re[5]: Тесты устойчивые ко времени выполнения
От: fmiracle  
Дата: 22.02.17 17:19
Оценка:
Здравствуйте, Pek2014, Вы писали:

F>>Ну да. Для C# совсем не сложно реализовать TimeService и с методом GetCurrentDateTime() и следить чтобы все по проекту его использовали. Ну собственно если человек будет писать юнит-тесты у него сразу возникнет вопрос "как же сверить что дата была проставлена текущая?", а ответ уже есть.

P>Понятно. Спасибо.
P>А если у вас нет возможности повлиять на проект в целом?

1. сделать для использования в своих классах, для которых ты и пишешь свои тесты.
2. пытаться повлиять на проект в целом, если есть желание изменить весь мир к лучшему
Re[3]: Тесты устойчивые ко времени выполнения
От: Sshur Россия http://shurygin-sergey.livejournal.com
Дата: 22.02.17 19:44
Оценка:
Здравствуйте, Pek2014, Вы писали:

P>Хочу уточнить: вы САМИ так делаете? Или вы это чисто теоретически?

P>Ведь этим компонентом должны пользоваться все, кому нужно текущее время.
P>Это должно быть решение на уровне всего проекта, централизовано?

да, нет, да

есть технологии, которые обеспечивают соответствие написанного кода принятым в конкретной организации правилам — TDD, code review.

без такого сервиса невозможно будет написать тесты. без тестов код не должен пройти код ревью. При возникновении вопроса "а как написать тест" новичку должен быть показан существующий сервис. Если он догадается написать свою копию не спросив — опять же на код ревью должен быть показан правильный вариант
Шурыгин Сергей

"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re[3]: Тесты устойчивые ко времени выполнения
От: · Великобритания  
Дата: 22.02.17 23:02
Оценка:
Здравствуйте, Pek2014, Вы писали:

P> Способ 1. Следить (обязать, ввести правило), чтобы не было "тайного"

P> использования текущего времени. Тем процедурам, результат которых зависит от
Это правило будет следовать из "обязать писать тесты".
avalon/2.0.1
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.