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:

dennisgorelik

> проверять весь сервис целиком для разных случаев надёжнее

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

From:

mikkim08

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

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

From:

dennisgorelik

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

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

> или false negative evaluation result

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

From:

mikkim08

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

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

From:

dennisgorelik

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

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

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

From:

mikkim08

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

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

From:

dennisgorelik

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

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

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

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

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:

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). Я не вижу тут неполного покрытия.