juan_gandhi | TWIMC: tests using random and current time

Entry tags:

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

Менее надежно может быть, например потому, что результат внутренней функции (TimeToGreeting()) может быть искажен в коде, который его вызывает.
Соответственно, integration test может начать выдавать либо false positive evaluation result, либо false negative evaluation result.

Здесь я Вас не понял. Можно примеры false positive evaluation result или false negative evaluation result ?

> примеры false positive evaluation result

Тест утверждает, что Greeting формируется правильно.
А на самом деле, Greeting формируется неправильно (ошибка в TimeToGreeting()), но из-за дополнительного кода, в некоторых случаях общий результат в integration test - все равно правильный.

> или false negative evaluation result

Тест утверждает, что результат неправильный.
А на самом деле, результат правильный.
Просто код, который вызывает TimeToGreeting() - отрезал кусок Greeting, потому что он оказался слишком длинным [и не входит в Tweet/Email subject/Whatever].

Тест утверждает, что Greeting формируется правильно.
А на самом деле, Greeting формируется неправильно (ошибка в TimeToGreeting()), но из-за дополнительного кода, в некоторых случаях общий результат в integration test - все равно правильный.

А мы не тестируем функцию TimeToGreeting. Нас интересует только сервис как таковой. Ведь пользователю неважно, что там внутри. Важно, чтобы сервис выдавал правильные ответы на запросы.

> А мы не тестируем функцию TimeToGreeting.

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

Однако, если мы тестируем "только сервис как таковой", то предположение, что достаточно протестировать лишь пару edge cases -- вполне может оказаться неверным.
Что поставит нас в весьма затруднительное положение: оставлять only 2 test cases -- плохо, но и добавлять дополнительные test cases -- тоже плохо (too brittle tests).

1) Мы вполне можем сделать предположения об имплементации сервиса, упрощающие тестирование, тестируя при этом сервис целиком, а не тестируя функцию TimeToGreeting.

2) Почему дополнительные тесты помимо двух это too brittle tests ?

> Мы вполне можем сделать предположения об имплементации сервиса

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

> Почему дополнительные тесты помимо двух это too brittle tests ?

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

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

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

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

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

Edited 2020-08-24 22:46 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Multiple separate places to modify code

dennisgorelik - 2020-08-26 20:09 (UTC) - Expand

Re: Multiple separate places to modify code

mikkim08 - 2020-08-26 20:12 (UTC) - Expand

Tests self-diagnostic

dennisgorelik - 2020-08-26 20:20 (UTC) - Expand

Re: Tests self-diagnostic

mikkim08 - 2020-08-27 20:11 (UTC) - Expand

Re: Tests self-diagnostic

dennisgorelik - 2020-08-27 23:35 (UTC) - Expand

Re: Tests self-diagnostic

juan_gandhi - 2020-08-27 23:39 (UTC) - Expand

Re: Tests self-diagnostic

dennisgorelik - 2020-08-28 00:19 (UTC) - Expand

Re: Tests self-diagnostic

juan_gandhi - 2020-08-28 03:16 (UTC) - Expand

Re: Tests self-diagnostic

dennisgorelik - 2020-08-28 08:48 (UTC) - Expand

Re: Tests self-diagnostic

mikkim08 - 2020-08-28 19:57 (UTC) - Expand

Re: Tests self-diagnostic

dennisgorelik - 2020-08-29 00:52 (UTC) - Expand

Re: Tests self-diagnostic

mikkim08 - 2020-08-29 20:33 (UTC) - Expand

Re: Tests self-diagnostic

dennisgorelik - 2020-08-29 21:52 (UTC) - Expand

Re: Tests self-diagnostic

mikkim08 - 2020-08-30 17:12 (UTC) - Expand

Re: Tests self-diagnostic

sassa_nf - 2020-08-29 08:12 (UTC) - Expand

Re: Tests self-diagnostic

mikkim08 - 2020-08-29 20:35 (UTC) - Expand

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

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

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

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

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

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

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

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

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

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

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

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

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