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

> Добрый вечер", "Добрый день", или "Доброе утро" в зависимости от своего местного времени.

В данном случае, достаточно extract deterministic метод:
static string TimeToGreeting(DateTime time) { ... }
и покрыть его тестами.
Зачем, в данном случае, mocks?

From:

juan_gandhi

Разумеется. Если такой, правильно написанный, код - то и проблемы нету!

From:

dennisgorelik

Так если код написан неправильно и есть проблема с его тестированием, то ведь, обычно, оптимальный подход - refactor такой код до правильного состояния, верно?

From:

juan_gandhi

В целом да; но не всегда получается.

From:

dennisgorelik

If in many cases it is possible to separate nondeterministic function and test it separately, then in these cases your recommendation ["if your code is written as something that retrieves this kind of data, to test your code, you should provide that data"] is not correct, right?

From:

juan_gandhi

There's no such thing as "nondeterministic function".

From:

dennisgorelik

> There's no such thing as "nondeterministic function".

Do you mean that your personal lexicon does not contain "nondeterministic function" concept?
~~~~~~~
https://www.google.com/search?q=%22nondeterministic+function%22
About 6,000 results
~~~~~~~

From:

juan_gandhi

"almighty god allah" finds over 7m records. And? It's also in my personal lexicon.

From:

dennisgorelik

> "almighty god allah" finds over 7m records

~~~~~~~~
https://www.google.com/search?q=%22almighty+god+allah%22
About 292,000 results
~~~~~~~~

You used "almighty god allah" without quotes in your search query...

> It's also in my personal lexicon

So you understand what people want to express when they write "Nondeterministic function"?
Then why do you refuse to use "Nondeterministic function" term to communicate that concept -- in order to clearly communicate your message?

"Nondeterministic function" is less ambiguous than "function".

From:

juan_gandhi

You seem to be seriously determined to teach me math.

From:

dennisgorelik

Communication, not math.

From:

mikkim08

В таком случае Вы протестируете только "TimeToGreeting", а не целый сервис, который по запросу возвращает приветствие.

From:

dennisgorelik

> Вы протестируете только "TimeToGreeting", а не целый сервис

Так целый сервис тоже тестировать. Но в целом тесте проверять только ту часть, которая не зависит от времени.

С моками, кстати, тесты тоже не полностью все покрывают.

From:

mikkim08

Так целый сервис тоже тестировать. Но в целом тесте проверять только ту часть, которая не зависит от времени.

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

Edited Date: 2020-08-24 08:49 pm (UTC)

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 - более очевидна.