Есть ли многоуровневая модульная система тестирования/junit addon?

Question

Представьте два сервера (каждый в собственном процессе JVM), которые обмениваются данными, используя некоторую форму сообщений (например, простой производитель/потребитель)

я хотел бы писать тесты, которые проверят поведение этих двух серверов ,
Мои вопросы:

1. Существуют определенные структуры (или их JUnit аддон) для этой проблемы?
   Я хотел бы запустить тестовый класс junit (или даже один тест) в другом процессе? Было бы здорово, если бы один модульный тест мог легко получить доступ к переменным другого теста (в другом процессе), используя какую-то межпроцессную связь.
   . Я хочу, чтобы проверить, действительно ли производитель произвел вещи, которые я ожидал, а затем, если потребитель их потреблял. (и, возможно, сделать некоторые неудобства, чтобы обнаружить некоторые проблемы, связанные с гоночными условиями)

2. Есть ли какая-то передовая практика для такого рода испытаний?

3. Если не существует единого подхода к тестированию, как бы вы провели во время непрерывной интеграции?

Примечание:
Я не хочу использовать потоки, так как это может изменить поведение (если вы думаете о вопросах безопасности потоков)

Answer 1

Я бы описал, что вы хотите сделать в качестве теста интеграции, и выходит за рамки JUnit как рамки (JUnit только теперь погружается в многопоточное тестирование, многопроцессор, конечно, не входит в функцию задавать).

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

Другие уже указали на то, что вы обычно высмеивали или иным образом отправляли искусственно сконструированные методы потребителю и проверяли, что производитель производит самостоятельно на уровне «единичного теста».

С точки зрения фактического тестирования взаимодействия между производителем и потребителем, один из подходов заключается в том, чтобы забыть о межпроцессном тестировании и протестировать его внутри процесса в одном потоке с помощью какой-либо инъекции зависимостей, когда производитель отправляет сообщение через какой-то поддельный способ, который просто передает его потребителю без каких-либо изменений под капотом, чем вызовы метода in-thread.

Однако кажется, что вы хотите проверить вещи, которые могут произойти с фактическим материалом межпроцессного взаимодействия (условия гонки и т. П.), Что делает этот тест более тесным.

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

Необходимость здесь должна быть для меня неотразимой. Я бы пошел на полномасштабное автоматизированное приемочное тестирование, и пусть это охватит этот уровень интеграции.

Answer 2

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

Вы также можете проверить механизм, с которым взаимодействуют два, но я бы ожидал, что это предоставлено третьей стороной?

См Mockito, jMock, EasyMock

Answer 3

То, что вы говорите в пункте 1, не является истинным сценарий модульного тестирования. В идеальном модульном тесте вы не будете беспокоиться о том, кто производит сообщения и кто потребляет сообщения. Один из ваших тестов будет сконцентрирован на том, чтобы вообразить (или издеваться), что вы получили разные сообщения от действительного производителя, и ваши тестовые примеры будут проверять, как они потребляются должным образом. То, что вы ищете, больше похоже на интеграционное тестирование. В любом случае некоторые из заявлений, которые я сделал, могут быть субъективными. Вы можете использовать jMock, рамки easymock для ваших издевательских потребностей.

Answer 4

Это нестандартное тестирование и твердое тестирование интеграции.

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

В таких случаях я делал это в прошлом, чтобы запустить отдельный поток в тесте, который запускает Mock Receiver/Sender. В основном тесте я делаю часть отправителя/получателя. На практике это означает, что это полон задержек, чтобы убедиться, что все началось в правильном порядке, и это становится мертвым медленно, поэтому вы просто хотите сделать это, чтобы проверить, что части головоломки подходят, и сделать как можно меньше функционального тестирования Это.

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

Это может протестировать много. Тестирование с использованием отдельных процессов (и хостов!) - настоящая боль. берет навсегда, и я бы ограничил это ручным тестированием.

Answer 5

Вы должны взглянуть на XHarness, который, я считаю, соответствует вашим потребностям. Я использовал его в недавнем прошлом, и он отлично работал для наших проектов в то время.

Со своей страницы:.

«XHarness является тестовой системой Жгутого Apache Ant позволяет разработчикам описать их продукт/системные тесты в форме XML как часть муравьиной сборки файл, описывающие задачи и процессов, которые включают тестовые случаи и что ожидаемое поведение является. обладает мощным управления технологическими процессами возможности,, которые расширяют существующие Задачи процесса Ant (exec, java) до позволяют использовать асинхронное выполнение java и собственные процессы (например, для клиент-серверных тестов), синхронизация между несколькими процессами и сложностью утверждение о выходе процесса и задачи (stdout/stderr, выход файла, связанный с таймаутами и т. д.). "