Обрабатывать события Swing в тесте JUnit

Question

У меня есть Java-приложение Swing с сетевым взаимодействием с несколькими «Игроками», которые представлены как объекты игроков, каждый из которых имеет свой собственный коммуникационный поток. В приложении есть объект «Команда», управляющий всеми объектами игрока. Несколько компонентов пользовательского интерфейса прослушивают события, передаваемые игроками через объект Team.

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

Еще немного фона. Сначала я сделал так, чтобы объект Team запускал свои события в потоках объекта player (без переключения потоков). Модульное тестирование команды прошло успешно, но я столкнулся с множеством проблем с многопоточностью в моем пользовательском интерфейсе с invokeLaters и синхронизировался повсеместно. Затем я решил упростить модель потоков, добавив события запуска объекта Team в поток Swing, но теперь модульный тест Team не проходит, поскольку он не получает события. Что делать?

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

Answer 1

Когда я провел тестирование JUnit с EventQueue.invokeLater, я отделился от этой злой статики. Создайте интерфейс с invokeLater is isDispatchThread методами. Для производства реализация должна просто переслать EventQueue. Для тестирования используйте свой собственный поток (который можно настроить и удалить для каждого теста).

Несколько других случайных советов:

• Сохраняйте графический интерфейс максимально тонким.
• Держите потоки вне всего остального, и все остальное из потока.
• С подозрением относитесь ко всему, что утверждает, что оно поточно-ориентированное.

Answer 2

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

Я не знаю, так ли это здесь, но я часто нахожу, что «сложность», которую я добавляю, на самом деле является более высоким уровнем абстракции, которая улучшает код.

Первоначальная идея ложных объектов заключалась не в том, чтобы упростить модульное тестирование, а в «открытии интерфейса», в создании интерфейсов, которые представляют абстракции в вашем вездесущем языке, а не работают на уровне API.

Answer 3

Возможно, вы можете использовать easymock, чтобы изолировать классы, которые вы хотите протестировать, и заставить фиктивные объекты получать события и проверять, что они запущены.

Я бы порекомендовал EasyMock: http://www.easymock.org/

Из вашей истории кажется, что ваши юнит-тесты - это более сложные интеграционные тесты. Если это так, попробуйте упростить и изолировать. Вы, наверное, прочитали http://junit.sourceforge.net/doc/testinfected/testing.htm

Надеюсь, это поможет.