Существует ли фреймворк для многопроцессного модульного тестирования / надстройка junit?
Представьте себе два сервера (каждый в рамках собственного процесса jvm) , которые обмениваются данными с помощью некоторой формы сообщений (например, У меня следующие вопросы:
Существуют ли какие-нибудь фреймворки (или аддон junit) для решения этой проблемы?
Я бы хотел запустить тестовый класс junit (или даже отдельный тест) в другом процессе? Было бы здорово, если бы один модульный тест мог легко получить доступ к переменным другого теста (в другом процессе), используя своего рода межпроцессное взаимодействие.
Например, я хотел бы проверить, действительно ли производитель произвел то, что я ожидал, а затем, потребил ли их потребитель. (и, возможно, провести фаззинг, чтобы обнаружить проблемы, связанные с условиями гонки)Есть ли лучшие практики для такого рода тестирования?
Если не существует подхода к модульному тестированию, как бы вы тестировали такие вещи во время непрерывной интеграции?
Примечание:
Я не хочу использовать потоки, потому что это может изменить поведение (если вы думаете о проблемах безопасности потоков)
4 ответа
Я бы описал то, что вы хотите сделать, как интеграционное тестирование, которое выходит за рамки JUnit как фреймворка (JUnit только сейчас погружается в многопоточное тестирование, многопроцессность, конечно, не входит в набор функций).
Вы, конечно, можете использовать JUnit для запуска таких тестов, но они будут действительно ограничены бегунком, остальное вам придется делать самим.
Другие уже указывали на тот факт, что обычно вы будете имитировать или иным образом посылать искусственно созданные методы потребителю, и тестировать то, что производит производитель, независимо на уровне "unit test".
С точки зрения фактического тестирования взаимодействия между производителем и потребителем, один из подходов заключается в том, чтобы забыть о межпроцессном тестировании, и тестировать его внутри процесса в одном потоке с помощью своего рода Dependency Injection, где производитель посылает сообщение каким-то поддельным способом, который просто передает его потребителю без чего-либо большего, чем внутрипотоковые вызовы методов.
Однако, похоже, что вы хотите проверить вещи, которые могут произойти с реальным межпроцессным материалом поверх него (условия гонки и тому подобное), что делает это тем более интеграционным тестом.
Чтобы решить эту проблему, вам нужно запустить процесс и подождать, пока он примет сообщение, затем ваш тест скажет производителю, какое сообщение создать, и он отправит его потребителю. Затем тест должен спросить потребителя, что он получил (с соответствующей задержкой).
Потребность в этом должна быть убедительной, чтобы я пошел на это. Я бы пошел на полномасштабное автоматизированное приемочное тестирование и позволил бы ему охватить этот уровень интеграции.
Я бы порекомендовал использовать фиктивные объекты, после чего вы можете протестировать производителя и потребителя независимо друг от друга. Итак, вы проверяете, что производитель производит, а потребитель потребляет.
Вы также можете протестировать механизм связи между ними, но я бы ожидал, что это будет предоставлено третьей стороной?
То, о чем вы говорите в пункте 1, не является настоящим сценарием модульного тестирования. В идеальном модульном тестировании вы не будете беспокоиться о том, кто производит сообщения и кто их потребляет. Один из ваших тестовых примеров будет сконцентрирован на том, чтобы представить (или сымитировать), что вы получили различные сообщения от действительного производителя, а ваши тестовые примеры будут проверять, как они правильно потребляются. То, что вы ищете, больше похоже на интеграционное тестирование. В любом случае, некоторые утверждения, которые я сделал, могут быть субъективными. Вы можете использовать jMock, easymock фреймворки для ваших потребностей в мокинге.
Это выходит далеко за рамки модульного тестирования и находится внутри интеграционного тестирования.
Я бы порекомендовал проверить, что вы можете, смоделировав свой слой связи с каждым отдельным фрагментом.
Раньше в таких случаях я запускал отдельный поток в тесте, который запускал фиктивный получатель / отправитель. Затем в основном тесте я выполняю часть отправителя / получателя.На практике это означает, что здесь полно задержек, чтобы убедиться, что все начинается в правильном порядке, и это становится очень медленным, поэтому вы просто хотите сделать это, чтобы проверить, подходят ли части головоломки, и как можно меньше проводить функциональное тестирование. Это.
Я проверяю желаемое поведение и завершаю вспомогательный поток перед выходом из теста.
Это может многое проверить. Тестирование с использованием отдельных процессов (и хостов!) - настоящая боль. занимает вечность, и я бы ограничился ручным тестированием.