juan_gandhi | TWIMC: tests using random and current time

So, if you think you call a function in your code, and this function returns current time, or a random number... IT'S NOT A FUNCTION. Your code is function of "random number", or "time".

So, if your code is written as something that retrieves this kind of data, to test your code, you should provide that data. Not just today, but try the time, like 10 years from now. As to "random", You provide the randomness. If your code cannot be fixed to behave as a function of those inputs, make your "random stream" or "time stream" not hard-coded, but substitutable. Mockable. And mock it in your tests. MAKE SURE that you don't provide just happy-path data. Provide anything. A sequence of 100 numbers 4 for random. Time that is 10 years from now. Or even 30 yeas from now.

Make sure that your tests don't depend on anything. Because test Must Be Reproducible.

All these things, I know, are obvious to some, and not obvious to others.

If you still have questions, ask. But don't argue. Because what I say is math. Unless you have another math (some people do), or another logic (there's plenty of them), please don't argue.

I'd be glad to see how all this changes if logic is e.g. linear.

Flat | Top-Level Comments Only | Expand All

From:

mikkim08

Но такие предположения "о структуре сервиса в целом" - гораздо менее надежные, чем предположения по структуре TimeToGreeting.

Отнюдь. Весь сервис ненамного сложнее TimeToGreeting.

Например потому, что при изменении списка возвращаемых значений, наши тесты, которые опираются на эти значения - тоже придется менять.

Мне это не кажется большим недостатком. Особенно в сравнении с тем, что зато мы покрываем тестами весь сервис.

Edited Date: 2020-08-24 10:46 pm (UTC)

From:

dennisgorelik

> Весь сервис ненамного сложнее TimeToGreeting.

Если весь сервис - ненамного сложнее, то и предположения о структуре делать не намного сложнее.
Но, все равно, сложнее.
И есть еще риск того, что сервис станет сложнее в будущем.

> Мне это не кажется большим недостатком.

Необходимость изменять данные в двух местах - отнимает дополнительное время и создает существенные проблемы.

> зато мы покрываем тестами весь сервис

Так ведь не покрываем весь сервис.
Потому что мы тестируем mocks, а не полный оригинальный сервис.

From:

mikkim08

И есть еще риск того, что сервис станет сложнее в будущем.

То же самое можно сказать и о функции TimeToGreeting.

Необходимость изменять данные в двух местах - отнимает дополнительное время и создает существенные проблемы.

В двух местах это в смысле и в имплементации сервиса, и в тестах для него ?

Так ведь не покрываем весь сервис. Потому что мы тестируем mocks, а не полный оригинальный сервис.

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

Edited Date: 2020-08-25 06:19 am (UTC)

From:

dennisgorelik

>> риск того, что сервис станет сложнее в будущем.

> То же самое можно сказать и о функции TimeToGreeting.

Да, но риск от усложнения функции TimeToGreeting, которая напрямую покрыта юнит тестами -- меньше. Потому что:
1) Меньше потенциального шума между тестами и функцией TimeToGreeting.
2) Наличие тестов у функции TimeToGreeting более очевидно.
3) Принадлежность тестов к функции TimeToGreeting - более очевидна.

From:

mikkim08

Тогда, наверное, нужно стремиться к тому, чтобы риск от усложнения всего сервиса был не больше чем риск от усложнения функции TimeToGreeting. Я думаю, это можно сделать.

From:

dennisgorelik

> нужно стремиться к тому, чтобы риск от усложнения всего сервиса был не больше чем риск от усложнения функции TimeToGreeting.

Это какая-то странная цель.

Если я очень сильно увеличу риск от усложнения функции TimeToGreeting, то ваша цель вполне может быть достигнута, верно?
Но непонятно, зачем нужно достигать такую странную цель.

From:

mikkim08

Конечно, хотелось бы снизить риск от усложнения сервиса, а не увеличить риск от усложнения функции TimeToGreeting.

From:

dennisgorelik

>> Необходимость изменять данные в двух местах - отнимает дополнительное время и создает существенные проблемы.

> В двух местах это в смысле и в имплементации сервиса, и в тестах для него ?

Да.
Не так уж и важно что это за два места. Проблематично, что таких мест - больше одного.

From:

mikkim08

Мне кажется это естественным. Если меняются требования, то нужно переделывать и тесты, и сам сервис.

From:

dennisgorelik

> Если меняются требования, то нужно переделывать и тесты, и сам сервис.

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

From:

mikkim08

Бывает, конечно, по-разному, и "хрупкие" тесты, которые нужно всё время переделывать, я тоже не люблю, но в целом тот факт, что при изменении требований нужно переделывать и сервис, и тесты, меня не очень заботит.

From:

dennisgorelik

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

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

From:

mikkim08

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

Потому что можно же одно из мест упустить из виду. Тесты, обычно, помогают самодиагностироваться, но не всегда.

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

From:

From:

mikkim08 - Date: 2020-08-29 08:35 pm (UTC) - Expand

From:

dennisgorelik

> ещё не обсуждали, как имплементировать сервис и mocks.

Если при тестировании с помощью mocks, в тестах приходится делать какие-то дополнительные операции, которые не делаются в production code, то такое тестирование с помощью mocks -- не покрывает весь сервис.
В частности, не покрыта та часть, которая делает то же, что делают тесты, манипулируя mocks.

From:

mikkim08

Тут я уже запутался. В особенности из-за последней фразы.

From:

dennisgorelik

Mock тестирование - не просто передает параметры в тестируемую функцию, но и делает дополнительные операции (обычно устанавливает значения некоторых properties у mock объекта), верно?

Аналоги этих дополнительных операций -- выполняются и при регулярном выполнении production code, верно?

Так вот эти аналоги (части production code) -- не покрыты mock тестами.
То есть покрытие неполное.

From:

mikkim08

Я не вполне согласен.

Представьте, что в код, который исполняет new DateTime(), передаёся какой-нибудь DateTimeCreator с методом newDateTime(), и все вызовы new DateTime() меняются на вызовы newDateTime().

Теперь в production мы передаём одну имплементацию DateTimeCreator, а в тестах -- другую (я называю её, возможно ошибочно, mock). Я не вижу тут неполного покрытия.

From:

dennisgorelik

У вас получилось хорошее описание примера использования mock.

> в production мы передаём одну имплементацию DateTimeCreator,

Так вот эта "production" имплементация -- и не тестируется.
И процесс передачи этой "production" имплементации -- тоже не тестируется.

Это и делает тестовое покрытие с помощью mocks - неполным.

From:

juan_gandhi

Да... мои соболезнования твоим сотрудникам.

From:

mikkim08

DateTimeCreator можно тоже покрыть тестами.
Процесс его передачи, наверное, тоже.

From:

dennisgorelik

> DateTimeCreator можно тоже покрыть тестами.

Если можно покрыть тестами DateTimeCreator, то зачем нужен Mock, подменяющий DateTimeCreator?

> Процесс его передачи, наверное, тоже.

Можно. В полноценном integration тесте, который не использует Mock.