Swing - это один из самых мощных инструментов для разработки приложений с графическим пользовательским интерфейсом (GUI); он отличается расширяемостью, конфигурируемостью и кросс-платформенностью. Но гибкость Swing, будучи его главной силой, также является его самой заметной слабостью. С помощью Swing один и тот же пользовательский интерфейс можно сделать многими способами. Например, для создания промежутков между компонентами интерфейса можно использовать классы Insets, EmptyBorder или Filler. При таком обилии возможностей понимание написанного на Swing кода графического пользовательского интерфейса может быть такой же сложной задачей, как написание нового, а соотнесение внешнего вида интерфейса и лежащего в его основе кода может быть совсем не тривиальным. (Попробуйте представить себе интерфейс при прочтении нескольких строк кода, в которых используется GridBagLayout.)

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

Хорошим началом работы является написание функциональных тестов с целью понять, как GUI реагирует на действия пользователя. Писать тесты для GUI сложнее, чем для неграфического кода, потому что:

• В идеале тесты должны быть автоматизированы, но GUI-интерфейсы предназначены для использования людьми, а не компьютерными программами.
  
  
• Традиционные модульные тесты, проверяющие работу классов по отдельности, не подходят для проверки GUI-компонентов. В случае GUI "модуль" включает в себя взаимодействие нескольких GUI-компонентов, каждый из которых может состоять более чем из одного класса.
  
  
• GUI отвечает на генерируемые пользователем события. Для тестирования GUI необходимо имитировать действия пользователя, дождаться, пока все слушатели будут оповещены о сгенерированных событиях, а затем проверить результат в том виде, в каком он был бы показан пользователю. При написании кода, имитирующего взаимодействия пользователя с GUI, легко ошибиться, а сам процесс кодирования может быть утомительным.
  
  
• Функциональные тесты должны быть надежными и не должны ломаться при изменении разметки GUI.

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

• какие представленные в GUI компоненты нужно протестировать
• каким образом идентифицировать в тесте эти компоненты
• в каком состоянии должен оказаться компонент (или его атрибуты) в результате теста

Нужно уметь определять структуру GUI с помощью визуальных инструментов проектирования (например, Matisse из NetBeans). Однако подобные инструменты показывают только информацию, доступную на момент верстки GUI; она может отличаться от того, как приложение выглядит во время выполнения. Например, некоторые компоненты могут становиться видимыми или невидимыми в зависимости от действий пользователя.

Традиционные отладчики не могут помочь вам определить состояние GUI во время выполнения какого-либо сценария. Когда отладчик останавливается на точке останова, помещенной в коде Swing, отрисовка GUI прерывается, в результате чего вместо GUI показывается пустой экран. В идеале хотелось бы наблюдать за поведением GUI во время пошагового выполнения его кода в отладчике.

К счастью, есть два инструмента с открытым кодом - Swing Explorer и FEST-Swing, которые могут помочь вам быстро разобраться в существующем коде Swing. В этой статье мы познакомимся с этими инструментами и рассмотрим, как их использовать совместно для изучения структуры графического интерфейса приложения, тестирования его функциональности и выявления потенциальных проблем.

Приложение для изучения

В большинстве примеров этой статьи в качестве тестируемого приложения я буду использовать удобный бесплатный редактор HTML под названием HTMLDocumentEditor (см. Ресурсы). Если вы хотите самостоятельно проработать примеры, загрузите приложение и код примеров. На рисунке 1 показан снимок запущенного приложения HTMLDocumentEditor:

Перед написанием тестов для GUI необходимо понять, из чего состоит данный GUI-интерфейс. HTML-редактор - это достаточно простое приложение, состоящее из области ввода текста и нескольких меню для открытия, сохранения и редактирования HTML-документов.

Также важно знать конкретный тип каждого компонента, чтобы знать какие действия или атрибуты из API компонента мы можем использовать в своих тестах. Для HTML-редактора нам нужно определить, чем является область ввода текста: JTextArea, JTextPane или каким-либо пользовательским GUI-компонентом. Один из способов определить тип компонентов - это изучение исходного кода. В зависимости от реализации это может быть простой или весьма сложной задачей. Код приложения HTMLDocumentEditor легок для чтения и понимания, поэтому, взглянув на него, можно сказать, что область ввода текста является компонентом JTextPane. Но в какой-нибудь момент вы можете столкнуться с плохо написанным и трудным для понимания кодом GUI. Когда это случится, можно потратить значительное время на расшифровку этого кода или же воспользоваться одним из инструментов, который эффективно выполнит для вас эту работу.

В начало

Знакомимся со Swing Explorer

Swing Explorer позволяет визуально изучать внутренности GUI-интерфейсов Swing (см. Ресурсы). Его простой и интуитивный пользовательский интерфейс позволяет легко распознать все компоненты изучаемого GUI, понять, как они нарисованы, посмотреть значения их атрибутов в любой момент времени и т.д.

Swing Explorer распространяется и как отдельное приложение, и в качестве модуля расширения для Eclipse и NetBeans. Рекомендованный способ его использования - через модуль расширения. В этой статье я буду работать с его модулем расширения для Eclipse (см. Ресурсы).

После установки модуля расширения я с помощью Swing Explorer запускаю основной класс HTML-редактора, как показано на рисунке 2:

Swing Explorer предоставляет несколько окон, которые помогут вам понять внутренности GUI-интерфейса Swing:

1. Дерево, представляющее иерархию графических компонентов
2. Исследуемый GUI-интерфейс
3. Панель с вкладками, показывающая атрибуты выбранного компонента (имя, размер и т.д.). Также на ней содержатся и другие полезные и интересные инструменты (см. Ресурсы)

С помощью Swing Explorer можно легко разобраться в структуре GUI. Предположим, что мы, глядя на исходный код, не можем определить тип компонента, используемого в HTML-редакторе в качестве области ввода текста. Используя Swing Explorer, мы просто выбираем область ввода текста в дереве компонентов или щелкаем по самому компоненту в отображаемом GUI. На рисунке 3 видно, как Swing Explorer сообщает нам, что область ввода текста является компонентом JTextPane:

В начало

Изучаем и тестируем поведение приложения

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

Для начала выберем для тестирования два сценария:

1. Открытие HTML-файла
2. Изменение цвета шрифта документа

Сейчас мы готовы начать написание функциональных тестов для GUI.

Функциональное тестирование GUI проверяет, что приложение работает так, как от него ожидается. Оно сконцентрировано на поведении приложения, а не на внешнем виде GUI. При создании надежных функциональных тестов для GUI важны следующие факторы:

• Нужно уметь имитировать работу пользователя (клавиатурой или мышью).
• Нужно иметь надежный механизм поиска GUI-компонентов.
• Нужно чтобы тесты не ломались при изменении расположения или разметки компонентов.

Неподходящий вариант: использование класса Robot напрямую

Чтобы гарантировать, что автоматические тесты "честно" имитируют действия пользователя, нужно генерировать на уровне операционной системы события, подобные тем, что происходят, когда пользователь работает с клавиатурой или мышью. JDK начиная с версии 1.3 предоставляет возможности имитировать действия пользователя с помощью класса Robot библиотеки Abstract Window Toolkit (AWT). Но Robot работает с координатами экрана, а не ссылками на компоненты Swing, поэтому, если использовать в тестах непосредственно его, тесты будут ненадежными, так как они могут ломаться из-за малейшего изменения разметки GUI.

К тому же Robot - слишком низкоуровневый инструмент; он умеет только нажимать кнопки мыши и клавиши клавиатуры. Придется писать код, транслирующий высокоуровневые действия, такие как "выбери третий элемент этого раскрывающегося списка", в действия Robot. На это может потребоваться много времени в зависимости от количества действий, которые нужно выполнить в вашем тесте, и компонентов, с которыми нужно работать. К тому же AWT Robot не предоставляет надежного механизма поиска компонентов (например, найти кнопку с текстом "OK"). Этот код также придется писать самостоятельно.

В общем, работа непосредственно с классом Robot из AWT требует немало времени и сил. При написании функциональных тестов для GUI нужно сосредоточиться на поведении, которое мы хотим проверять, а не на средствах, делающих тестирование GUI возможным.

Знакомимся с FEST-Swing

Модуль FEST (Fixtures for Easy Software Testing) Swing - это библиотека, которая позволяет легко создавать и поддерживать надежные и функциональные тесты для GUI. Отметим его следующие характеристики:

• Имитация действий пользователя в FEST Swing основана на классе Robot из AWT.
  
  
• Компактный, интуитивный и легкий для понимания интерфейс FEST Swing упрощает создание и сопровождение функциональных тестов для GUI. В листинге 1 показан пример кода, реализующий высокоуровневые действия: ввести текст "luke" в текстовое поле firstName и нажать кнопку "ok":
  
  Листинг 1. Удобный интерфейс FEST-Swing
  

  dialog.textBox("firstName").enterText("Luke"); dialog.button("ok").click();

  
  
• Методы-проверки (assertion), проверяющие состояние GUI-компонентов. В листинге 2 показан метод requireText, проверяющий, что надпись с именем "answer" содержит текст "21":
  
  Листинг 2. Методы-проверки в FEST-Swing
  

  dialog.label("answer").requireText("21");

  
  
• Создание надежных тестов, которые не ломаются при изменении разметки графического интерфейса.
  
  
• Поддержка компонентов Swing, представленных в JDK.
  
  
• Поддержка JUnit 4 и TestNG.
  
  
• Проверка правильности использования Swing в потоках.
  
  
• упрощение поиска причин поломки тестов.
  
  

В начало

Пишем функциональные тесты для GUI с помощью FEST-Swing

Итак, мы поняли структуру GUI-интерфейса приложения, определили сценарии, для которых мы хотим создать тесты, и нашли надежный инструмент тестирования. Все готово для написания функциональных тестов для GUI.

Сценарий: открытие HTML-файла

Открытие файла в HTML-редакторе включает в себя следующие действия:

1. Открываем меню File > Open
2. В появившемся окне выбираем файл, который мы хотим открыть
3. Проверяем, что редактор загружает содержимое файла

В листинге 3 показан код этого сценария:

public class HTMLDocumentEditor_Test extends FestSwingJUnitTestCase {


   private FrameFixture editor;

   protected void onSetUp() {
     editor = new FrameFixture(robot(), createNewEditor());
     editor.show();
   }

   @RunsInEDT
   private static HTMLDocumentEditor createNewEditor() {
     return execute(new GuiQuery<HTMLDocumentEditor>() {
       protected HTMLDocumentEditor executeInEDT() {
         return new HTMLDocumentEditor();
       }
     });
   }

   @Test
   public void should_open_file() {
     editor.menuItemWithPath("File", "Open").click();
     JFileChooserFixture fileChooser = findFileChooser().using(robot());
     fileChooser.setCurrentDirectory(temporaryFolder())
                .selectFile(new File("helloworld.html"))
                .approve();
     assertThat(editor.textBox("document").text()).contains("Hello");
   }
}

Рассмотрим подробно, что делает код из листинга 3:

• В первой строке объявляется класс, расширяющий класс FestSwingJUnitTestCase модуля FEST-Swing. Этот класс обеспечивает автоматическое создание Robot-а FEST-Swing, проверку правильности использования Swing в потоках (позднее мы расскажем об этом подробнее) и автоматическую очистку ресурсов (закрытие открытых окон, освобождение мыши и клавиатуры, и т.д.).
  
  
• editor = new FrameFixture(robot(), createNewEditor()); создает новый объект FrameFixture, умеющий имитировать действия пользователя в окне (Frame) приложения, искать внутри него компоненты (используя различные критерии поиска) и проверять их состояние.
  
  
• editor.show(); отображает на экране HTML-редактор.
  
  
• @RunsInEDT информирует, что метод createNewEditor() гарантированно будет выполняться в потоке диспетчеризации событий (EDT).
  
  
• return execute(new GuiQuery<HTMLDocumentEditor>() создает в EDT новый экземпляр HTMLDocumentEditor.
  
  
• Методом editor.menuItemWithPath("File", "Open").click(); FEST-Swing имитирует нажатие пользователем меню File > Open.
  
  
• Методом JFileChooserFixture fileChooser = findFileChooser().using(robot()); FEST-Swing находит окно "Open File" (компонент JFileChooser).
  
  
• В следующих трех строках FEST-Swing имитирует выбор пользователем файла helloworld.html, находящегося в каталоге временных файлов.
  
  
• Метод assertThat(editor.textBox("document").text()).contains("Hello"); удостоверяется в том, что файл загрузился в редактор, проверяя, что в области ввода текста редактора содержится слово Hello.

Обратите внимание, что код в листинге 3 ищет компонент JTextPane по имени (editor). Это наиболее надежный способ поиска компонентов в тестах, так как он гарантирует, что поиск компонентов не сломается даже при изменении разметки GUI в будущем.

Сценарий: изменение цвета шрифта документа

Чтобы проверить, что HTML-редактор задает желтый цвет шрифта документа, нам нужно:

1. Выбрать меню Color > Yellow
2. Набрать в редакторе какой-нибудь текст
3. Проверить, что введенный текст - желтого цвета

В листинге 4 показано, как это можно сделать с помощью FEST-Swing:

@Test
public void should_change_document_color() {
  editor.menuItemWithPath("Color", "Yellow").click();
  JTextComponentFixture textBox = editor.textBox();
  textBox.enterText("Hello");
  assertThat(textBox.text()).contains("<font color=\"#ffff00\">Hello</font>");
}

До сих пор мы тестировали простые GUI-компоненты, такие как меню и текстовые поля. Далее мы рассмотрим более сложный тестовый сценарий.

Более сложный тест

Продемонстрируем, как интуитивный и понятный API библиотеки FEST-Swing позволяет работать с одним из довольно сложных компонентов Swing - JTable.

Я воспользуюсь приложением TableDialogEditoDemo из руководства по Swing от Sun (см. Ресурсы). В этом приложении используется JTable с пользовательскими компонентами: JComboBox и JCheckBox, как показано на рисунке 4:

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

1. При необходимости прокрутить содержимое таблицы вверх или вниз, чтобы сделать строку 0 видимой.
2. Нажать на ячейку в строке 0, столбце 2.
3. Подождать появления выпадающего списка.
4. Найти выпадающий список и нажать на него.
5. Выбрать второй элемент выпадающего списка.

Это лишь высокоуровневое описание действий, которые необходимо запрограммировать. Написание самого кода - это нетривиальная задача. К счастью, как показано в листинге 5, API, предоставляемый FEST-Swing, делает эту задачу довольно простой:

dialog.table.enterValue(row(0).column(2), "Knitting");

FEST-Swing упрощает написание и чтение тестов для GUI, даже довольно сложных.

В начало

Работа Swing в потоках

Swing - однопоточная библиотека. Так как она не является потокобезопасной, весь код Swing должен выполняться в потоке EDT. В официальной документации Swing говорится, что работа с кодом Swing в нескольких потоках одновременно может привести к конфликтным ситуациям в потоках или ошибкам целостности данных (см. Ресурсы).

Правила потокобезопасности Swing гласят:

• Компоненты Swing должны создаваться в потоке EDT.
• Работа с компонентами Swing должна осуществляться в потоке EDT, исключение составляют методы, документированные как потокобезопасные.

Хотя эти правила кажутся простыми, нарушить их довольно просто. Swing во время выполнения не осуществляет никаких проверок правильности использования потока EDT и можно легко сделать в Swing вроде бы "хорошо работающий" графический интерфейс, нарушающий эти правила.

И Swing Explorer, и FEST-Swing предоставляют средства для поиска нарушений правил потокобезопасности Swing. На рисунке 5 показан входящий в Swing Explorer инструмент EDT monitor. EDT monitor может рапортовать о нарушениях правил работы с EDT во время выполнения приложения.

В FEST-Swing имеется класс FailOnThreadViolationRepaintManager, выявляющий нарушения использования EDT, который при их обнаружении завершает тест с ошибкой. Настроить этот класс очень просто: установите его в методе настройки, помеченном аннотацией @BeforeClass, как показано в листинге 6:

@BeforeClass public void setUpOnce() {
  FailOnThreadViolationRepaintManager.install();
}

Также вы можете делать тесты наследниками входящего в FEST-Swing класса FestSwingTestngTestCase или FestSwingJunitTestCase, в которых FailOnThreadViolationRepaintManager уже установлен. FEST-Swing также предоставляет полезные абстракции, проверяющие, что работа с компонентами Swing осуществляется в EDT. С более подробной информацией по этой теме можно ознакомиться в разделе Ресурсы.

В начало

Отладка ошибок в тестах для GUI

Независимо от библиотеки, используемой при написании функциональных тестов для GUI, этот тип тестов уязвим по отношению к различным сторонним событиям тестовой среды. FEST-Swing не является исключением. Например, антивирус, выполняющий запланированную проверку системы, может вывести диалог, блокирующий GUI, который вы тестируете. Robot библиотеки FEST-Swing не сможет получить доступ к GUI. В конце концов произойдет сбой работы по таймауту, что приведет к ошибке в тесте. Причиной такого сбоя не является ошибка программирования; он вызван неудачным стечением обстоятельств.

Полезной функциональностью FEST-Swing является его умение делать снимки рабочего стола в момент возникновения ошибки в тесте. Эти снимки можно автоматически встраивать в отчеты JUnit или TestNG, а также сохранять в директорию при выполнении единичного теста из IDE. На рисунке 6 показан HTML-отчет JUnit с ошибкой в тесте для GUI. Обратите внимание на добавленный библиотекой FEST-Swing снимок, сделанный в момент возникновения ошибки теста.

Другой типичной причиной отказа тестов являются ошибки поиска компонентов. Рекомендуется искать компоненты по уникальным именам. Но иногда компоненты графического интерфейса, который нужно тестировать, не имеют уникальных имен. В таком случае приходится разрабатывать собственные критерии поиска. Существует два типа ошибок поиска компонентов:

1. GUI-компонент невозможно найти. Например, предположим, мы ищем компонент JTextField с именем firstName, тогда как разработчик забыл назначить компоненту это имя. В подобных случаях FEST-Swing добавляет в выдаваемое исключение ComponentLookupException иерархию имеющихся компонентов, чтобы было легче обнаружить причину ошибки. В данном примере можно изучить иерархию компонентов, чтобы посмотреть, присвоено ли компоненту JTextField правильное имя и был ли он вообще показан в GUI. В листинге 7 показана иерархия компонентов, выводимая в исключении ComponentLookupException:
   
   Листинг 7. Исключение ComponentLookupException, содержащее в себе иерархию компонентов
   

   org.fest.swing.exception.ComponentLookupException: Unable to find component using matcher org.fest.swing.core.NameMatcher[name='ok', requireShowing=false]. Component hierarchy: myapp.MyFrame[name='testFrame', title='Test', enabled=true, showing=true] javax.swing.JRootPane[] javax.swing.JPanel[name='null.glassPane'] javax.swing.JLayeredPane[] javax.swing.JPanel[name='null.contentPane'] javax.swing.JTextField[name='name', text='Click Me', enabled=true]

   
   Иерархия компонентов в листинге 7 помогает нам сделать вывод, что разработчик дал компоненту JTextField неправильное имя. Компонент называется name вместо firstName.
   
   
2. Найдено более одного GUI-компонента. Это происходит, если заданным критериям поиска удовлетворяют несколько GUI-компонентов. Например, имя firstName могло быть по ошибке назначено двум компонентам JTextField. В таком случае поиск компонента JTextField с именем firstName (а за ним и тест) заканчивается неудачей, так как искомое имя имеют два компонента. Чтобы помочь диагностировать проблему, выдаваемое исключение ComponentLookupException выводит все найденные компоненты, удовлетворяющие условиям поиска, как показано в листинге 8:
   
   Листинг 8. Исключение ComponentLookupException, cодержащее список компонентов, удовлетворяющих заданным критериям поиска
   

   org.fest.swing.exception.ComponentLookupException: Found more than one component using matcher org.fest.swing.core.NameMatcher[ name='firstName', type=javax.swing.JTextField, requireShowing=false]. Found: javax.swing.JTextField[name='firstName', text='', enabled=true] javax.swing.JTextField[name='firstName', text='', enabled=true]

   
   

Иногда бывает сложно проанализировать иерархию компонентов в исключении ComponentLookupException, особенно при работе с GUI, состоящим из большого количества компонентов. В этом Swing Explorer нам также может помочь. Как мы уже видели, можно выбирать и изучать атрибуты любого компонента иерархии, просто нажав на нём мышью. Большие иерархии компонентов намного проще изучать с помощью Swing Explorer, чем используя их текстовое представление, выводимое в исключении ComponentLookupException.

В начало

Заключение

За мощь Swing приходится платить его сложностью; понять код Swing может быть так же трудно, как написать его. Написание тестов для изучения неизвестного кода GUI - более сложная задача, чем написание тестов для неграфического кода. К счастью, Swing Explorer и FEST-Swing могут помочь исключить рутину и гадания из этого процесса. С помощью Swing Explorer можно изучать структуру GUI непосредственно на работающем приложении. Поняв структуру и поведение тестируемого GUI, можно начать писать для него функциональные тесты, используя компактный и интуитивный API библиотеки FEST-Swing. Помимо лаконичного API, FEST-Swing предлагает средства для проверки правильного использования Swing в потоках, а также возможности, которые помогут вам экономить время при анализе ошибок тестов. В этой статье мы рассмотрели лишь малую часть возможностей, предоставляемых этим дуэтом инструментов.

Инструменты Swing Explorer и FEST-Swing очень полезны, однако еще лучшим решением был бы инструмент для записи и воспроизведения тестовых сценариев, записывающий действия пользователя в код Java, такой, который будто бы был создан вручную разработчиком. Инструменты для записи и воспроизведения сценариев позволяют сделать набор тестов в кратчайшее время. Вы взаимодействуете с существующим GUI, и все генерируемые при этом события записываются в сценарий. Впоследствии можно проиграть этот сценарий, чтобы воспроизвести действия пользователя. Главной слабостью существующих инструментов для записи и воспроизведения сценариев является дороговизна сопровождения сгенерированных тестов. Любое изменение в приложении требует повторной записи всех тестовых сценариев. В то же время при записи похожих тестовых сценариев может возникать дублированный тестовый код,. Зачастую записанные сценарии длятся продолжительное время и сохраняются на запатентованных языках с недостаточной поддержкой объектно-ориентированного программирования. Разделение повторяющихся действий на модули здесь является трудоемкой и подверженной ошибкам работой, которая, как правило, требует изучения нового языка программирования.

Используя инструмент записи/воспроизведения сценариев, основанный на популярном и зрелом объектно-ориентированном языке - Java, программисты могли бы работать в средах IDE, повышающих производительность и сокращающих издержки за счет ускорения и упрощения выполнения рутинных и подверженных ошибкам задач (например, рефакторинга). Именно над этим работает команда проекта FEST, разрабатывая инструмент записи/воспроизведения сценариев, генерирующий понятные объектно-ориентированные тесты, работающие с API библиотеки FEST-Swing. Ожидается, что предварительная версия этого инструмента будет готова к первому кварталу 2010 года.

В начало

Загрузка

Информация о методах загрузки

Ресурсы

Научиться

• Оригинал статьи: Debugging and testing Swing code (Alex Ruiz, developerWorks, февраль 2010 г.). (EN)
  
  
• Посетите сайт проекта Swing Explorer. (EN)
  
  
• На сайте FEST-Swing можно найти ссылки на документацию, статьи и страницу загрузки библиотеки. (EN)
  
  
• Writing EDT-safe Swing UI tests (блог Алекса Руиса, июль 2009 г.): узнайте, как писать тесты, соблюдающие правила потокобезопасности Swing. (EN)
  
  
• In pursuit of code quality: Automate GUI testing with TestNG-Abbot (Эндрю Гловер, developerWorks, февраль 2007 г.): почитайте о тестировании GUI с помощью TestNG-Abbot, предшественника FEST-Swing. (EN)
  
  
• WYSIWYG Html Editor with JEditorPane and HTMLEditorKit (Artima.com, февраль, 2002 г.): Чарльз Белл разместил здесь исходный код приложения HTMLDocumentEditor. (EN)
  
  
• How to Use Tables: ознакомьтесь с руководством по работе с таблицами в Swing. (EN)
  
  

Получить продукты и технологии

• Загрузите Swing Explorer или его модуль расширения для IDE. (EN)
  
  
• Загрузите FEST-Swing. (EN)
  
  

Обсудить

• Подпишитесь на рассылку Swing Explorer или изучайте ее архивы. (EN)
  
  
• Подпишитесь на рассылку FEST Users' Group. (EN)
  
  

Об авторе

Алекс Руис любит читать материалы, связанные с разработкой на Java, тестированием, объектно-ориентированным программированием, аспектно-ориентированным программированием и параллельными вычислениями. Программирование - это его первая любовь. Алекс является создателем FEST - инновационной Java-библиотеки, призванной облегчить тестирование приложений на основе Swing и JavaFX и тестирование в целом. Он работает программистом в подразделении Oracle, занимающемся инструментами разработки ПО. До работы в Oracle Alex работал консультантом в ThoughtWorks. Посетите блог Алекса.

Оценить эту статью

Комментарии

В начало

Содержание

• Знакомимся со Swing Explorer
• Изучаем и тестируем поведение приложения
• Пишем функциональные тесты для GUI с помощью FEST-Swing
• Работа Swing в потоках
• Отладка ошибок в тестах для GUI
• Заключение
• Загрузка
• Ресурсы
• Об авторе
• Комментарии