Проверить поведение параллельного кода

Question

У меня есть объект, который после получения некоторых сообщений изменяется асинхронно (внутренний поток изменяет состояние). После изменения состояния я хочу проверить какое-то поведение.

Поэтому в основном мне нужно сделать что-то вроде:

1. Создать объект
2. Отправить сообщение для объекта
3. Дождитесь состояния, чтобы изменить
4. поведение Тест

Однако, состояние частный и не подвергается.

Есть ли элегантное решение для этого, которое не требует раскрытия состояния?

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

Answer 1

Если государство является закрытым, оно доступно только в пределах его собственного класса (https://docs.oracle.com/javase/tutorial/java/javaOO/variables.html), что означает, что вы не сможете получить состояние из только что созданного объекта без изменения класса.
Теперь, разумно ли это изменить класс для того, чтобы сделать некоторые испытания до нескольких факторов:

• Сколько людей работают над этим кодом?
• Сколько людей уже использует предыдущую версию этого кода?
• Проблемы с целостностью, с которыми вам придется столкнуться, если вы измените переменную состояния на общедоступную и добавите метод геттера.
• т.д.

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

Answer 2

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

Foo bar = new Foo(); 
    bar.setValue(true); 

    Field field = Foo.class.getDeclaredField("value"); 
    field.setAccessible(true); 
    Object value = field.get(bar); 

Это значение будет храниться в частной переменной в классе.

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

Answer 3

Общий шаблон для тестирования асинхронного кода заключается в блокировании основного тестового потока, чем утверждение чего-либо в обратном вызове async после его выполнения перед разблокированием основного тестового потока. Вот пример использования ConcurrentUnit:

final Waiter waiter = new Waiter(); 

bus.registerMessageHandler(message -> { 
    waiter.assertEquals(message.body(), "foo"); 
    waiter.resume(); 
}); 

waiter.await(5000); 

Этот тест создает официанта, который ждет в течение 5 секунд. Обратный вызов, зарегистрированный на шине сообщений, будет выполнять утверждение в отдельном потоке до возобновления официанта, чтобы тест мог завершиться.

Уловка, вы, очевидно, должны иметь возможность подключить какой-то обратный вызов/обработчик в приложение. Если вы просто ожидаете изменения какого-либо состояния, и вы полностью не видите его видимости, то вы не можете сделать так, чтобы утверждать, что состояние изменено.