смотрите на ГРУШУ пакет XML_Serializer . Я использовал его с довольно хорошими результатами. Можно питаться, это выстраивает, объекты и т.д., и это превратит их в XML. Это также имеет набор опций как выбор названия корневого узла и т.д.
, Должен добиться цели
Обратите внимание, что, вообще говоря, модульное тестирование элементов пользовательского интерфейса всегда сложно, потому что вам нужно высмеивать множество вещей, которые просто недоступны.
Поэтому основная цель при разработке приложений (любого типа) - всегда стараться отделить элементы пользовательского интерфейса от основной логики приложения, насколько это возможно. Наличие здесь сильных зависимостей делает модульное тестирование действительно сложным, по сути, кошмаром. Обычно это достигается за счет использования таких шаблонов, как подход MVC , при котором вы в основном тестируете свои классы контроллеров, а классы представления ничего не делают, кроме создания пользовательского интерфейса и делегирования своих действий и событий контроллерам. Это разделяет обязанности и упрощает тестирование.
Более того, вам необязательно тестировать вещи, которые уже предоставляются фреймворком, такие как проверка правильности запуска событий. Вам следует просто проверить логику, которую вы пишете, самостоятельно.
Look this:
FEST is a collection of libraries, released under the Apache 2.0 license, whose mission is to simplify software testing. It is composed of various modules, which can be used with TestNG or JUnit...
Проверьте проект uispec4j. Это то, что я использую для тестирования своих пользовательских интерфейсов.
Я думаю, что проблема с тестированием обнаруживает проблему с кодом. На самом деле модель не должна решать, работает ли она в потоке отправки, это слишком много обязанностей. Он должен просто выполнять свою работу по уведомлению и позволить вызывающему компоненту решить, вызывать его напрямую или invokeLater. Этот компонент должен быть в той части кода, которая знает о потоках Swing. Этот компонент должен знать только о файлах и т. Д.
Я работаю с jMock всего два дня ... так что, пожалуйста, извините, если есть более элегантное решение. :)
Похоже, ваша FileTableModel зависит от SwingUtilities ... вы не думали издеваться над используемыми SwingUtilities? Один из способов, который пахнет взломом, но решит проблему, - это создать интерфейс, скажем ISwingUtilities, и реализовать фиктивный класс MySwingUtilities, который просто перенаправляет на настоящие SwingUtilities. А затем в своем тестовом примере вы можете смоделировать интерфейс и вернуть true для isEventDispatchThread.
@Test
public void testEventsNow() throws IOException {
IFile testDir = mockDirectoryStructure();
final ISwingUtilities swingUtils = context.mock( ISwingUtilities.class );
final FileSystemEventsListener listener =
context.mock(FileSystemEventsListener.class);
context.checking(new Expectations()
{{
oneOf( swingUtils ).isEventDispatchThread();
will( returnValue( true ) );
oneOf(listener).currentDirectoryChanged(with(any(IFile.class)));
}});
FileTableModel model = new FileTableModel(testDir);
model.setSwingUtilities( swingUtils ); // or use constructor injection if you prefer
model.switchToInnerDirectory(1);
}