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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс. Требования уже проясняются. Подумай ещё. У тебя выразится дезигн, а тесты сами придут исходя из требований.