questionerПонятно, что имплементацию таски пишу я сам, но как оттестировать тот факт, что некоторые таски не исполнялись параллельно

Семафор какой-нибудь. Пушишь две "непараллельные" таски. Одна блочит семафор и спит (условную) секунду. Вторая в течении той же (условной) секунды проверяет, что семафор свободен.

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

Тестится. Я ловил в тестах ошибку.
Да, надо понимать, что вероятность упасть при ошибке не 100%, но т.к. CI гоняет их постоянно- то проблемы обычно всплывают. Правда надо внимательно писать, чтобы не поймать лишних ошибок.

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


Не ударжелся, написал .
Г@внокод, понятное дело. Ну да, мозги надо включать и с первого раза не заработает - ну так красные ленточки на входе были
Если поправить код около "//!!!" тут и тут то можно словить ошибки.

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

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

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

maytonУ нас JMS реально нужен. :) Для нашей системы это natural way.

Тогда зачем тестировать ответ?

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

Ну это как раз интеграционные тесты. А на subj можно и unit

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

Поставь один поток- тест упадёт. Значит тестирует.

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

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

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

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

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

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

Всё просто. Каждая задача выполняется секунду. У нас 5 задач. Через 1.5 секунды в очереди нет задач- значит параллельная работат есть.
Проверим. Сделаем всё в один поток - получим падение теста. Значит проверка есть.

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

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

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

Зачем? А если тест гоняется на древнем одноядерном процессоре, то он упадёт, что ли?
В реальности всё одно потоки ждут обычно- обычно сеть, или диск. В крайнем случае память. Загрузить ядро работой даже на 50%- это большая удача.

Не надо ударяться в софистику. стоит вполне конкретная задача топикстартера. Этот тест её решает.

Я писал код, в котором, к примеру, можно было выполнять к серверу не более 5 запросов в секунду, при этом ответы были медленные, поэтому работало 30 потоков.
Тесты были, первоначальные ошибки поймали, потом код работал сутками и ограничения не превышал. Так что тесты писать можно. Было бы желание.

questionerПродвинутые люди сказали, что надо писать тесты на jcStress

Классная штука.
Но, насколько я понял, это black-box тест. Если так, то это не замена, а дополнение самописным тестам.
white-box тестирование тоже нужно делать.

scfВторая - тестирование многопоточного кода в одном потоке. Как известно, при выполнении корректно синхронизированного многопоточного кода он разворачивается в так называемый synchronization order, в котором операции идут строго последовательно.

Извините, но это бред.

[/quote]И вместо этого использовать ScheduledExecutor. Запустить два куска кода параллельно? Загрузите обе таски в екзекутор. Запустить их последовательно? Загрузить в екзекутор первую таску и в конце её загрузить вторую. Нужно сделать паузу? Загрузить таску в SheduledExecutor с нужной задержкой. Нужна более сложная система координации тасок? ConcurrentLinkedQueue<Runnable> в помощь.

Всё это нужно писать на скале или хотя бы на джаве с CompletableFuture.

Тестировать такой многопоточный код можно, просто сделав мок экзекутора, который будет запускать свои таски в нужном для теста порядке.[/quote]


Во-первых у ScheduledExecutor'а есть вариант однопоточной работы.
Во-вторых ничего вы так не поймаете.
Вот, к примеру, последняя ошибка в многпоточном коде, которую я поймал, была связана с тем, что после выполнения задачи выполнялось две операции- запись в mongo статуса задачи и удаление из map'ы в памяти. Именно в таком порядке.
Иногда (ОЧЕНЬ иногда) другой (из 30, ага) поток успевал схватить свободную задачу и записать в map'у. После этого первый поток удалял задачу из map'ы и второй потом выдавал exception (т.к. в map'е нет его задачи).
Тест автор кода поленился написать. Искали ошибку долго (тем более, что на 20 нодах с 30 потоков каждая ошибка случалась раз в сутки). Но тест (который падал) я, когда нашёл ошибку, написать смог
А Ваш вариант не найдёт такую ошибку никогда.

scfСледите за руками:
...
Примерно так.

Каждый тест должен что-то проверять. unit-тест проверяет конкретный небольшой кусок кода с минимальным объёмом не относящегося к делу кода.
Автору нужно проверить, что некоторый executor не выполняет одновременно задачи, которые это явно запрещают.
Т.е. нужно взять наш executor (именно тестируемый, а не какой-то другой), затем вложить в него набор задач (простейших, без побочного кода) и проверить, что при возможности исполнить задачи параллельно некоторые не будут работать одновременно.
Лучше проверить, что тест работает- для этого надо внедрить ошибку "все последовательно" и "всё параллельно" и увидеть, как тест упал (параллельность такое дело- там да, надо проверять правильность тестов).
То, что Вы написали не имеет отношения к делу- executor другой, а задачи те же. Зачем?