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

S>Допустим вы сделали решение. Как вы его будете тестировать?
Решением такой задачи является некоторая state machine. Сначала мы формально доказываем, что дизайн state machine соответствует требованиям (сохраняет инварианты); затем просто аккуратно проверяем, что реализация машины соответствует дизайну.
BlackBox тестирование таких решений — прямая дорога в ад, по очевидным причинам. В частности, переход в конце девяностых к многоядерным процессорам выявил множество многолетних багов в реализациях многопоточки, которые были скрыты особенностями одноядерной многозадачности.

S>К примеру, такой кейс — восстановление сессии.

S>Допустим вы сделали решение. Как вы его будете тестировать?

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

Ты просто имей ввиду, как это со стороны смотрится. Уверен, не у меня одного так.

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

S>>Допустим вы сделали решение. Как вы его будете тестировать?
·>Вот сделай решение, покажи, будем посмотреть как его тестировать. Интерфейсы не тестируются, тестируется реализация.

Ну если TDD — сначала пишем тест, потом реализацию нам GPT сам пишет.

Но тут вопрос — как проверить что реализация действительно рабочая?

Функционал очень простой — если сессия устарела — вызываем метод ResetSession и потом получаем новую сессию RetrieveSession. Но нюанс — +- в одно время ResetSession могут вызвать 200 методов и так же затем вызывать RetrieveSession — а создать сессию нужно только 1 раз.

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

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

S>>>4. Нельзя восстанавливать сессию повторно, если уже раз восстановили.
D>>В тесте два раза вызываешь ResetSession и проверяешь отсутствие исключений в первый раз, и ожидаемое исключение — во второй.

S>Зачем исключение? Просто нужно ждать пока завершится первый запрос — и не делать запрос повторно. Вроде очевидно же

Пишешь мок на свой интерфейс и проверяешь в реализации мока проверку, что запрос не завершён. Это условия падения теста. А тестируется тут клиентский код, поэтому мокаем интерфейс и пишем туда тестовую логику. Это разве не очевидно? НО тест упал, и что твоя апликация должна сделать? У тебя нет никакого фидбэка что должно произойти, если это условие не выполнится, поэтому исключение. Разве ЭТО не очевидно?

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

S>Тут проблема вот в чем. Нужно как-то протестить что правильно расставлены блокировки, атомарные операции, нет кеширования в памяти (volatile где нужно) и пр. Т.е. даже правильный тест — может не всегда а лишь с определенной вероятностью обнаружить проблему. Но и даже правильный тест написать — так же под вопросом.

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

ПС.
постарайся не употреблять манупулятивные выражения типа "Вроде очевидно же". Оставь это для конспирологов. А здесь технический вопрос и технические детали, которых ты не предоставил, и подкидываешь по ходу. Имей уважение хотя-бы к тем, у кого спрашиваешь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования тут во многом интуитивно понятны — просто нужно восстановить сессию, если она устарела.

Тут в другом вопрос — как проверить что все корректно будет работать в многопоточной среде?

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

S>·>Вот сделай решение, покажи, будем посмотреть как его тестировать. Интерфейсы не тестируются, тестируется реализация.
S>Ну если TDD — сначала пишем тест, потом реализацию нам GPT сам пишет.
Ну так тогда у GPT и спрашивай. Сюда зачем пришёл?

S>Но тут вопрос — как проверить что реализация действительно рабочая?
Многопоточка в общем случае не тестируется никак. Поэтому сводят к каким-то более ограниченным примитивам. Скажем, у тебя там Task, вот от него и пляшем. Реализация будет куда-то лазить на новой сессией, вот это место и мокаем тестом в виде тамошнего Task, который завершаем в разные моменты и тестируем что получается.

Так что ещё раз. Начни с реализации, а там поглядим.

S>Функционал очень простой — если сессия устарела — вызываем метод ResetSession и потом получаем новую сессию RetrieveSession.
Какой-то корявый интерфейс. А если результат RetrieveSession тоже устареет? Начни с правильного дизайна.

S>Но нюанс — +- в одно время ResetSession могут вызвать 200 методов и так же затем вызывать RetrieveSession — а создать сессию нужно только 1 раз.
Ты пытаешься выжать гарантию корректности из blackbox тестирования? Ну успехов.

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

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

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

Т.е. порождает потоки — очевидно вызывающий код. Как бы сводите на малозначимое.

На каком ЯП вам удобнее привести пример, чтобы получилась конкретика?

К примеру, такой кейс — восстановление сессии.

interface ISessionProvider {
  Task<SessionResult> RetrieveSession();
  Task ResetSession();
}

Нужно чтобы:

1. Если сессия устарела (а этого ISessionProvider не знает — узнаем когда сделаем запрос) — то вызвать resetSession.
2. Может быть два одновременных запроса и каждый вызовет resetSession.
3. resetSession может быть вызван в момент, когда первый запрос уже начал восстановление сессии (а так же когда начал, почти начал, закончил, почти закончил).
4. Нельзя восстанавливать сессию повторно, если уже раз восстановили.

Допустим вы сделали решение. Как вы его будете тестировать?

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

S>К примеру, такой кейс — восстановление сессии.

S>

S>interface ISessionProvider {
S>  Task<SessionResult> RetrieveSession();
S>  Task ResetSession();
S>}
S>

S>Нужно чтобы:

S>1. Если сессия устарела (а этого ISessionProvider не знает — узнаем когда сделаем запрос) — то вызвать resetSession.

Это логика клиентского кода — тестами на провайдер это не покроется. Но если хочешь тестировать клиентский код — пиши мок на свой провайдер, возвращай "сессися протухла" из RetrieveSession, и удостоверься, что ResetSession вызван.

S>2. Может быть два одновременных запроса и каждый вызовет resetSession.

Тогда что должно произойти? Сформулируй условия, а потом будем их проверять.

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

Тогда что должно произойти? Сформулируй условия, а потом будем их проверять.

S>4. Нельзя восстанавливать сессию повторно, если уже раз восстановили.

В тесте два раза вызываешь ResetSession и проверяешь отсутствие исключений в первый раз, и ожидаемое исключение — во второй.

S>Допустим вы сделали решение. Как вы его будете тестировать?

Иди учи уроки!!!

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

S>>4. Нельзя восстанавливать сессию повторно, если уже раз восстановили.
D>В тесте два раза вызываешь ResetSession и проверяешь отсутствие исключений в первый раз, и ожидаемое исключение — во второй.

Зачем исключение? Просто нужно ждать пока завершится первый запрос — и не делать запрос повторно. Вроде очевидно же

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

Тут проблема вот в чем. Нужно как-то протестить что правильно расставлены блокировки, атомарные операции, нет кеширования в памяти (volatile где нужно) и пр. Т.е. даже правильный тест — может не всегда а лишь с определенной вероятностью обнаружить проблему. Но и даже правильный тест написать — так же под вопросом.

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

D>Пишешь мок на свой интерфейс и проверяешь в реализации мока проверку, что запрос не завершён. Это условия падения теста. А тестируется тут клиентский код, поэтому мокаем интерфейс и пишем туда тестовую логику. Это разве не очевидно? НО тест упал, и что твоя апликация должна сделать? У тебя нет никакого фидбэка что должно произойти, если это условие не выполнится, поэтому исключение. Разве ЭТО не очевидно?

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

S>>Тут проблема вот в чем. Нужно как-то протестить что правильно расставлены блокировки, атомарные операции, нет кеширования в памяти (volatile где нужно) и пр. Т.е. даже правильный тест — может не всегда а лишь с определенной вероятностью обнаружить проблему. Но и даже правильный тест написать — так же под вопросом.

D>Определись кто должен быть ответственным за соблюдением этих условий (провайдер или клиентский код) и что должно произоити, если услоия не выполняются. И это будем тестировать.

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

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

Еще один из негативных сценариев — провайдер не сделает ни одного запроса вообще.

З.Ы.
По идее при сбросе сессии — еще бы передавать какую именно сессию сбрасываем, а то иначе никак не понять — вдруг сбросим новую сессию, которую только что восстановили (уже после запроса на обновление).

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

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

D>>Пишешь мок на свой интерфейс и проверяешь в реализации мока проверку, что запрос не завершён. Это условия падения теста. А тестируется тут клиентский код, поэтому мокаем интерфейс и пишем туда тестовую логику. Это разве не очевидно? НО тест упал, и что твоя апликация должна сделать? У тебя нет никакого фидбэка что должно произойти, если это условие не выполнится, поэтому исключение. Разве ЭТО не очевидно?

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

S>>>Тут проблема вот в чем. Нужно как-то протестить что правильно расставлены блокировки, атомарные операции, нет кеширования в памяти (volatile где нужно) и пр. Т.е. даже правильный тест — может не всегда а лишь с определенной вероятностью обнаружить проблему. Но и даже правильный тест написать — так же под вопросом.

D>>Определись кто должен быть ответственным за соблюдением этих условий (провайдер или клиентский код) и что должно произоити, если услоия не выполняются. И это будем тестировать.

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

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

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

Определись или ожидание или 200 одновременно. Количество одновременных запросов должно быть внешним параметром. Если есть требования но одновременные запросы, то в моке делаем счётчик и проверяем.

S>Еще один из негативных сценариев — провайдер не сделает ни одного запроса вообще.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S>К примеру, такой кейс — восстановление сессии.
S>interface ISessionProvider {
S>Допустим вы сделали решение. Как вы его будете тестировать?
Вот сделай решение, покажи, будем посмотреть как его тестировать. Интерфейсы не тестируются, тестируется реализация.

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

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

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

S>Требования тут во многом интуитивно понятны — просто нужно восстановить сессию, если она устарела.

S>Тут в другом вопрос — как проверить что все корректно будет работать в многопоточной среде?

Чтобы проверять многопоточную среду — надо определить требования к этой среде.
— Кто управляет потоками, где они создаются, где уничтожаются?
— Какое состояние у этих потоков, как его можно получить?
— Как осуществляется коммуникация между этими потоками?

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

Ты привёл интерфейс с двумя методами. Да, у них есть названия, но требования не внятные (звучат как "сделай мне хорошо при условии, что я знаю чего хочу").
По мере обсуждений требований к твоему провайдеру, вдруг возникают требования и к клиентскому коду, и к тому, что стоит за этим провайдером.

Тесты обсуждаются когда дизайн готов. А так мы тут придумываем дизайн вместо обсуждения тестов.

Или ты просто на эффективного менеджера переучился (уж очень постановка задач похожа).

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

S>Допустим вы сделали решение. Как вы его будете тестировать?

можно моками, можно использовать санитайзеры, в данном случае TSAN

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

DP>Интересный у тебя способ просить совета у коллег. Настолько интересный, что отвечать не хочется. Еще и в священный войнах почему-то...
DP>Ты просто имей ввиду, как это со стороны смотрится. Уверен, не у меня одного так.

А вот реально встречали ли тесты для таких кейсов — именно для многопотока, а не просто в одном потоке?

Многопоток скорее просто смотрится на глаз и просто делается вывод что вроде все ОК.

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

S> Сводя к малозначимым вопросам.

Это самые значимые вопросы. Это архитектура. TDD — это когда архитектура уже есть, а не способ её разработки.

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

D>Это самые значимые вопросы. Это архитектура. TDD — это когда архитектура уже есть, а не способ её разработки.

Выше чел. правильно написал:

Решением такой задачи является некоторая state machine. Сначала мы формально доказываем, что дизайн state machine соответствует требованиям (сохраняет инварианты); затем просто аккуратно проверяем, что реализация машины соответствует дизайну.

Т.е. по сути авто-тесты — вряд ли возможны.

На каком ЯП вам привести пример, чтобы вы поняли свою ошибку?

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

S>На каком ЯП вам привести пример, чтобы вы поняли свою ошибку?

Мою ошибку в твоём кривом дизайне?
Ты победил.

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

D>Мою ошибку в твоём кривом дизайне?
D>Ты победил.

Все что ты говоришь — это относится к однопоточному приложению. Видел ли когда-нибудь тесты, направленные именно на проверку в многопотоке? Только честно.

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

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

D>>Мою ошибку в твоём кривом дизайне?
D>>Ты победил.

S>Все что ты говоришь — это относится к однопоточному приложению. Видел ли когда-нибудь тесты, направленные именно на проверку в многопотоке? Только честно.

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

Тебе надо знать что будет система дедать и как обрабатывать систуации когда это не согласуется (это то, чего в твоём дизаине нет в принципе).

Ты не можешь тестами задетектить дедлок, но ты можешь сделать дизаин таким, чтобы ты смог определить такую ситуацию и принать соответствующие меры (вот это ты в тестах и проверяешь).
Сделать ты это можешь, если у тебя всегда есть хендлы/указатели/ референсы на что-то, что во что у тебя обёрнуты потоки. Синхронизация должна быть с таймаутами (опять что-то, что можно протестировать), а это уже не просто lock{} из helloword и chatgpt, а что-то с контролем времени. Тебе нужно знать как очистить систему при возникновении ситуации, когда ты решаешь прибить сущетвующие задачи с соответствуйющим фидбеком вызывающей стороне, чтобы она также могла обработать эту ситуацию. А для этого тебе нуже вменяемый протокол обмена информацией между твоими потоками. Всего этого у тебя нет.

Весь это обвес и проверяешь в тестах мокая то один интерфейс то другой, дабы создать валидное/не валидное состояние.

И это называется архитектурой. А потом уже TDD.

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

S>Допустим вы сделали решение. Как вы его будете тестировать?

Никак, мы сразу правильно пишем.

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

D>Сделать ты это можешь, если у тебя всегда есть хендлы/указатели/ референсы на что-то, что во что у тебя обёрнуты потоки. Синхронизация должна быть с таймаутами (опять что-то, что можно протестировать), а это уже не просто lock{} из helloword и chatgpt, а что-то с контролем времени. Тебе нужно знать как очистить систему при возникновении ситуации, когда ты решаешь прибить сущетвующие задачи с соответствуйющим фидбеком вызывающей стороне, чтобы она также могла обработать эту ситуацию. А для этого тебе нуже вменяемый протокол обмена информацией между твоими потоками. Всего этого у тебя нет.

Для конкретного обсуждения нужно уточнить пример — указать язык/платформу. Потому что в некоторых случаях все исполняется вообще в одном потоке — что даже синхронизация не нужна (Future может вызывать системный вызов в другом потоке, но потом все-равно вернет управление в тот же поток). Но при этом все-равно возможна проблема с очередностью вызовов.

Если готовы не хорохориться перед девками а серьезно обсуждать — давай приведу пример на C#, к примеру.

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

S>Если готовы не хорохориться перед девками а серьезно обсуждать — давай приведу пример на C#, к примеру.

Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся.
Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).

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

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

D>Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся.
D>Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).

Дело в том что мой конкретный код — под Flutter. А это скорее язык мало распространен. Можно перевести на C#, но проблема в том что с потоками эти платформы работают совершенно по-разному. Хотя кое какие идеи сохраняются.

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

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

D>>Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся.
D>>Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).

S>Дело в том что мой конкретный код — под Flutter. А это скорее язык мало распространен. Можно перевести на C#, но проблема в том что с потоками эти платформы работают совершенно по-разному. Хотя кое какие идеи сохраняются.

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

Если хочешь что-то делать на новом языке/технологии — то, возможно, чат-бот и даст кое-какое представление, но для построения грамотной архитектуры желательно посвятить время на изучение нюансов, которых в helloword's просто нет ( а на таких примерах chat bot, в основном, и учится — это всё-же на главных страницах проектов — легко для парсинга).

С другой стороны разные пошаговые мануалы, полностью посвящённые отдельному нюансу, часто скрыты за регистрацией, поэтому таких примеров для обучения чат-боту не дали.

Серьёзно — это не долго изучить (проработать) нюансы , просто требует увлечённости и сосредоточения.

Вот суть.

Нормального способа такое тестировать я не знаю.

Если прям сильно надо — я бы так поступил:

1. Сделать спец-интерфейс вида interface DebugSynchronization { void wait(String point); }.

2. В реализацию класса пробросить этот интерфейс и во всех интересующих точках вызывать debugSynchronization.wait("pointname").

3. В продакшне использовать реализацию с пустым методом.

4. Для тестов использовать специальную реализацию, которой можно управлять. Т.е. запускаем интересующий нас метод в отдельном потоке, а из потока-теста вызываем что-то вроде waitForArrival("pointname"), resume("pointname"). Эти методы останавливают вызывающий поток, пока целевой поток не дойдёт до указанной точки (в этот момент тестируемый поток останавливается в wait) или продолжают выполнение тестируемого потока, который остановился в указанной точке.

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

Наверняка я не первый это придумал и такое уже есть в готовом виде.

Тут, конечно, не очень красиво получается, что в обычный код просочился тестовый. Ну лучше варианта не знаю.