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

S>>Провайдер, конечно — не должен делать повторный запрос, если уже запущен один из запросов на обновление сессии.

D>То есть провайдер — это обёртка. Тогда он и есть этих сессий. Вот то, что оборачиваешь — мокаешь и пишешь там тестовую логику, описанные выше.

Но тут нужно угадать по микросекундам — чтобы сделать попытку повторного запроса в нужный момент. Вдруг там не правильная проверка внутри.

Или же просто трезвым взглядом оценить что все ОК без всяких тестов. А вот как чтобы идеальный тест...

D>Когда ты говоришь дождаться завершения предыдущего запроса — а если дедлок, есть ли таймауты. Как это обрабатываем? Что должно произойти? Вот это и тестируем.

Ну, таймаут просто отразится на SessionResult.

А если дедлок — то что можно сделать — просто зависинет и все. Это и нужно проверить что дедлок не возникает.

D>Определись или ожидание или 200 одновременно.

Могут вызвать 200 одновременно, и 199 должны ждать а 1 обновлять сессию. Потом все 199 должны воспользоваться результатом того счастливчика, который начал первым.

D>Количество одновременных запросов должно быть внешним параметром. Если есть требования но одновременные запросы, то в моке делаем счётчик и проверяем.
D>В моке ожидаешь вызовов. Если не было — тест падает. Такое есть в популярных либах для тестов.

Тут проблема в том что все может зависеть от промежутков (в микросекундах) между вызовами. Или просто на глаз посмотреть что все ОК, понимать что тесты ничего не гарантируют.

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

S>>Провайдер, конечно — не должен делать повторный запрос, если уже запущен один из запросов на обновление сессии.

D>То есть провайдер — это обёртка. Тогда он и есть этих сессий. Вот то, что оборачиваешь — мокаешь и пишешь там тестовую логику, описанные выше.

Но тут нужно угадать по микросекундам — чтобы сделать попытку повторного запроса в нужный момент. Вдруг там не правильная проверка внутри.

Или же просто трезвым взглядом оценить что все ОК без всяких тестов. А вот как чтобы идеальный тест...

D>Когда ты говоришь дождаться завершения предыдущего запроса — а если дедлок, есть ли таймауты. Как это обрабатываем? Что должно произойти? Вот это и тестируем.

Ну, таймаут просто отразится на SessionResult.

А если дедлок — то что можно сделать — просто зависинет и все. Это и нужно проверить что дедлок не возникает.

D>Определись или ожидание или 200 одновременно.

Могут вызвать 200 одновременно, и 199 должны ждать а 1 обновлять сессию. Потом все 199 должны воспользоваться результатом того счастливчика, который начал первым.

D>Количество одновременных запросов должно быть внешним параметром. Если есть требования но одновременные запросы, то в моке делаем счётчик и проверяем.
D>В моке ожидаешь вызовов. Если не было — тест падает. Такое есть в популярных либах для тестов.

Тут проблема в том что все может зависеть от промежутков (в микросекундах) между вызовами. Или просто на глаз посмотреть что все ОК, понимать что тесты ничего не гарантируют.

К примеру, если вызов в момент выполнения запроса — ОК. А если вызов точно после завершения запроса (когда некий флаг обновили, но результат еще не установили) — то пойдет повторный запрос. Может же быть и такой сценарий.

Получается только глазом смотреть и давать гарантию под честное слово без всяких тестов?