Управление событиями Swing в тесте JUnit

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

• Держите GUI как можно тоньше.
• Держите резьбу из всего остального, и все остальное из нитей.
• Будьте подозрительны ко всему, что утверждает, что оно является потокобезопасным.

Answer 3

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

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

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