questionerДали задачку написать класс который исполняет задачи. Он может это делать параллельно в некоторых случаях, а в некоторых случаях это запрещено.

Просят написать тесты на эту функциональность. Что-то у меня в голове пазл не сходится как это сделать.

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

Если ты сможешь - то вынеси логику в отдельный черный ящик и протестируй ее. Без мультипоточности.

Ваш тест скорее всего настолько сложен что его тоже надо покрыть тестами

Alexey TominmaytonВаш тест скорее всего настолько сложен что его тоже надо покрыть тестами


Не ударжелся, написал .
Г@внокод, понятное дело. Ну да, мозги надо включать и с первого раза не заработает - ну так красные ленточки на входе были
Если поправить код около "//!!!" тут и тут то можно словить ошибки.
Спасибо. Я даже более скажу. У меня есть аналогичный код в тестах со sleep(..).
Но он не для мультипоточности а для JMS(Apache MQ). Дело в том что в некоторых
тестах в силу особенностей технологии нет синхронного assert. Все - асинхронные.
Стоишь как дурак и ждёшь. Придёт месседж или нет? Если не пришел сразу - то не факт
что fail(). Просто надо еще пол-минутки подождать.

Вот таков он этот JMS.

Alexey TominЧем дальше, тем больше прихожу к убеждению, что JMS используется намного больше, чем нужно. И даже можно.
Очередь/топик нужны только когда ответ вообще не нужен. Во всех остальных случаях есть инструменты и подходы лучше. Типа REST/gRPC и nginx/consul/костыли_в_mesos/... для отказа от конфигов.
Если надо ждать ответа от очереди- значит архитектор идиот.
Нет. У нас JMS реально нужен. :) Для нашей системы это natural way.

Тестируем потому что требование заказчика. Тесты - ендпоинт. То есть тестится не какой-то модуль а
Полный цикл работы приложения. Начиная от того как jms сообщение зашло.

Ваш тест не тестирует параллельной работы.

По сути он просто утверждает что экзекютор когда нибудь остановится.

И из него не очевидно что какая то работа была выполнена.

Давай порассуждаем. В чем смысл этого экзекютора. Не вникая в детали твоих групп и прочих категорий.

Я утверждаю что существует момент времени t _когда хотябы два потока работали одновременно.

Это главный поинт и его надо тестировать. Без него этот экзекютор фейк и его работу можно было сэмулировать
Как последовательную.

Как проверить параллельную работу? Вопрос достойный отдельного топика.

Мне кажется критерий потраченного времени - плохой советчик.

Ведь в реальности потока не стоят в sleep а исполняют работу?

Нужен пруф работы