Модульное тестирование компонентов J2EE-платформы: Часть 1. Модульное тестирование Java- и EJB-приложений

C использованием интегрированных сред JUnit и JUnitEE в IBM Rational Application Developer Version 6.0.2

Это первая часть серии из трех частей. В ней рассказывается, как можно использовать интегрированные среды тестирования с открытыми исходными кодами, такие как JUnit и JUnitEE, для модульного тестирования Java- и EJB-приложений, используя IBM Rational Application Developer Version 6 в среде IBM WebSphere Application Server Version 6.

Джон Даймонд, инженер-программист, IBM

Джон Даймонд (John Diamond) работает в IBM более 10 лет инженером-программистом и IT-специалистом на различных должностях. В настоящее время является членом Systems Technology Group Lab Services. Принимал активное участие в разработке WebSphere, Java и DB2. Имеет сертификат по Java. Имеет степени BA от Skidmore College и MBA от NYU.



Абрахам УолдМайкл, инженер-программист, IBM

Абрахам УолдМайкл (Abraham WoldeMichael) начал свою карьеру в IBM в группе технического тестирования различных продуктов IBM, использующих технологии J2EE и Web-сервисов. В настоящее время он работает в группе IBM Systems and Technology Group development, предоставляющей сервисы защиты для IBM Virtualization Engine, являющегося частью инициативы IBM On Demand. Имеет степень в области вычислительной техники и систем от Howard University, а также различные профессиональные IT-сертификаты.



03.05.2007

Почему необходимо модульное тестирование J2EE-компонентов

По мере продвижения к распределенным, многоуровневым и гетерогенным вычислениям технология J2EE (Java™ 2 platform, Enterprise Edition) становится самой популярной для разработки основанных на компонентах, многоуровневых, распределенных корпоративных приложений. Технология J2EE интегрирует клиентские приложения и апплеты, Web-компоненты (JSP и сервлеты) и EJB-компоненты (Enterprise JavaBeans™). Web и EJB-компоненты выполняются на сервере приложений, например, на сервере IBM® WebSphere® Application Server. При использовании технологии J2EE для разработки больших, сложных корпоративных приложений становится неизбежной ситуация, когда различные компоненты собираются вместе для формирования единого интегрированного приложения.

Перед такой компоновкой необходимо и критично важно выполнить должным образом независимое модульное тестирование каждого компонента. Изолированное модульное тестирование каждого компонента значительно уменьшает количество ошибок и гарантирует высокое качество программного обеспечения. Некоторые разработчики или тестировщики могут возразить, что модульное тестирование J2EE-компонентов требует слишком много времени и труда, а также подвержено ошибкам. Хотя подробное описание модульного тестирования различных J2EE-компонентов выходит за рамки данной статьи, в ней будет рассмотрена простота и эффективность модульного тестирования EJB-компонентов с использованием интегрированных сред тестирования JUnit и JUnitEE.

Модульный тест представляет собой написанный разработчиком фрагмент кода, использующий очень маленькую, специализированную область функциональности тестируемого кода. Обычно модульный тест исполняет некоторый конкретный метод в конкретном контексте; таким образом, он попадает в более широкую категорию тестирования белого ящика. Поскольку необходимость модульного тестирования J2EE-компонентов стала очевидной, разработчики начали использовать преимущества интегрированной среды JUnit для выполнения этих тестов. Интегрированная среда тестирования JUnit, первоначально написанная Энриком Гамма (Enrich Gamma) и Кентом Беком (Kent Beck), представляет собой среду для модульного тестирования клиентских Java-приложений. Она предлагает несколько преимуществ:

  • Простая интегрированная среда для написания автоматизированных, самопроверяющихся тестов на Java.
  • Поддержка тестовых утверждений (assertions).
  • Разработка наборов тестов.
  • Немедленные отчеты по тестам.

JUnit предоставляет текстовую командную строку, а также основанные на AWT и Swing графические механизмы составления отчетов по тестам. Интегрированная платформа разработки (integrated development platform - IDE) IBM Rational Application Developer содержит JUnit.

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

О данной серии статей

В данной серии статей, состоящей из трех частей, рассматривается использование инструментальных средств и технологий IBM для модульного тестирования Java-приложений, EJB-компонентов и Web-сервисов с помощью интегрированных сред тестирования JUnit и JUnitEE.

  • Часть 1 (данная статья) начинается с обзора JUnit и JunitEE. Затем демонстрируется использование JUnit и JUnitEE в Rational Application Developer IDE для модульного тестирования простого Java-приложения и несохраняющего состояние сессионного компонента. Сначала мы представляем краткий обзор структуры JUnit и JUnitEE, после чего объясняем, как разрабатывать и настраивать модульные тесты в интегрированных средах тестирования JUnit и JUnitEE. Наконец, мы демонстрируем, как развернуть и выполнить модульные тесты в среде сервера приложений.
  • В Части 2 рассматривается модульное тестирование Web-сервисов с использованием интегрированных сред JUnit и JUnitEE на платформе Rational Application Developer, а также рассказывается, как развернуть и выполнить модульные тесты в среде IBM WebSphere Application Server Version 6.
  • Часть 3 основана на материале второй части. В ней предоставляется пошаговое руководство по разработке, развертыванию и выполнению модульного тестирования EJB-компонентов и Web-сервисов с использованием JUnit и JUnitEE на платформе Rational Application Developer. Рассказывается также, как развернуть и выполнить тесты в среде IBM WebSphere Application Server.

Предварительные условия

Для наиболее эффективной работы с данной статьей необходимы общие знания Web-сервисов и Rational Application Developer. Web-сайт IBM® developersWorks® и раздел "Ресурсы" в конце статьи предоставляют ссылки на ознакомительные материалы.

Данное руководство было разработано и протестировано с использованием последних версий JUnitEE Version 1.10 и Rational Application Developer Version V 6.0.2. Можно загрузить пробную версию Rational Application Developer и двоичные файлы примера (см. раздел "Ресурсы").

Интегрированная среда тестирования JUnit

JUnit в настоящее время является неофициальным стандартом для модульного тестирования Java-приложений. Хотя Web-сайт Junit.org предоставляет подробную информацию и учебные руководства (см. раздел "Ресурсы"), в данном разделе мы приведем обзор интегрированной среды тестирования JUnit. Главным назначением API, составляющих JUnit, является ускорение и упрощение написания модульных тестов на Java. Контрольный пример JUnit имеет общую структуру, показанную в листинге 1.

Листинг 1. Общая структура JUnit
1.	Import junit.framework.TestCase;
2.	
3.	Public class AddJavaTest extends TestCase {
4.	
5.	protected void setUp() throws Exception
6.	    {
7.	     // создать некоторый объект
8.	    }
9.	protected void tearDown() throws Exception
10.	{
11.	 //освободить все ресурсы, созданные в       
12.	  setup()
13.	} 
14.	     public AddJavaTest (String name){
15.	           super (name);
16.	
17.	     public void testSimpleAddition (){
18.	            assertTrue (expect == actual);
19.	   }
}

Как показано в листинге 1 в строке 3, все Java™-классы должны расширять junit.framework.TestCase, являющийся базовым классом для JUnit. В строке 5 метод TestCase.setUp() переопределяется для инициализации или создания экземпляра тестируемого объекта. И наоборот, в строке 9 метод TestCase.tearDown() переопределяется для освобождения всех выделенных ресурсов. В строке 14 контрольный пример должен иметь конструктор с одним строковым параметром, который передает аргумент в его родительский класс (TestCase) с целью отображения имени контрольного примера в log-файле.

Метод контрольного примера должен быть объявлен как public void без формальных параметров. Кроме того, желательно предварить имя тестового метода словом "test", так чтобы исполнитель теста выполнил все методы автоматически. Наконец, в строке 18 исполняется выражение-утверждение (assertion) для определения успешности или неудачи выполнения контрольного примера. Метод assert сравнивает ожидаемое значение с реальным значением для конкретного тестового сценария. Вы можете использовать метод fail() для принудительного неудачного завершения теста, например, если хотите установить таймаут для операции. JUnit предоставляет дополнительный механизм для определения успешности или неудачи выполнения контрольного примера. В таблице 1 показана выборка различных сигнатур методов assert и fail.

Таблица 1. Методы assert
static voidassertEquals (boolean expected, boolean actual)
Утверждает, что два булевых значения равны.
static voidassertFalse (boolean condition)
Утверждает, что условие ложно.
static voidassertNotNull (java.lang.Object object)
Утверждает, что объект не равен null.
static voidassertNotSame (java.lang.Object expected, java.lang.Object actual)
Утверждает, что два объекта ссылаются не на один и тот же объект.
static voidassertNull (java.lang.Object object)
Утверждает, что объект равен null.
static voidassertSame
(java.lang.Object expected, java.lang.Object actual)
Утверждает, что два объекта ссылаются на один и тот же объект.
static voidassertTrue (boolean condition)
Утверждает, что условие истинно.
static voidfail (java.lang.String message)
Завершает тест неудачно с данным сообщением.
static voidfailNotEquals
(java.lang.String message, java.lang.Object expected, java.lang.Object actual)
private static voidfailNotSame
(java.lang.String message, java.lang.Object expected, java.lang.Object actual)
private static voidfailNotEquals
(java.lang.String message, java.lang.Object expected, java.lang.Object actual)
private static voidfailSame (java.lang.String message)
(package private) static java.lang.Stringformat (java.lang.String message, java.lang.Object expected, java.lang.Object actual)

Примечание: Класс Assert содержит много различных перегруженных методов. Полный список перегруженных методов assert приведен на странице JUnit.org http://www.junit.org/junit/javadoc/3.8.1/.

JUnit предоставляет класс TestRunner для выполнения контрольных примеров. Существуют различные способы выполнения тестов. Сообщения теста отображаются с использованием графики и текста. Для отображения графических, более популярных, результатов используются junit.swingui.TestRunner и junit.awtgui.TestRunner. Для менее популярных текстовых результатов используется junit.textui.TestRunner.

Кроме того, контрольные примеры JUnit могут быть запущены из IDE Rational Application Developer или автоматизированы в Ant-сценариях компоновки.

JUnit также предоставляет способ группировки тестов в набор, используя класс junit.framework.TestSuite. Набор тестов представляет собой композицию связанных тестов, которые могут выполняться в одной и той же сессии. Существуют два удобных способа выполнения контрольных примеров JUnit:

  • В первом способе передается тестовый класс в конструктор TestSuite с использованием следующей команды:
    TestSuite suite= new TestSuite(testAddJava.class)
    В этом случае TestRunner извлекает все тестовые методы, имеющие префикс test, а затем автоматически выполняет каждый контрольный пример.
  • Альтернативным способом является добавление каждого контрольного примера, используя метод TestSuite.addTest:
    TestSuite suite = new TestSuite(); suite.addTest(new AddJavaTest("testSimpleAddition"));

Интегрированная среда тестирования JUnitEE

JUnit предоставляет эффективный и удобный способ модульного тестирования клиентских Java-приложений, но он имеет ряд ограничений; по этой причине тестирование в контейнере любого сервера приложений становится трудоемким процессом. Платформа IBM Rational Application Developer имеет функциональность Web-based Universal Test Client (UTC), которая обеспечивает плавный и интегрированный механизм для модульного тестирования EJB-компонентов (Enterprise JavaBeans). Однако Rational Application Developer UTC является интерактивным механизмом модульного тестирования, поэтому он не может применяться для автоматизации модульных тестов.

Интегрированная среда тестирования JUnitEE преодолевает эти ограничения, а также уменьшает трудоемкость процесса. Данная среда расширяет стандарт JUnit таким образом, что он становится способным выполнять модульные тесты в контейнере сервера приложений. Она настраивается в J2EE Web-модуле приложения модульного тестирования и использует TestRunner для вывода результатов тестирования в формате HTML или XML. Она также содержит TestServlet для точки входа в контрольные примеры JUnit. Итак, согласно JUnitEE.org, создание тестов в виде стандартного J2EE Web-приложения предлагает следующие преимущества:

  • Тесты пакетируются в J2EE Web-модуль (в WAR-файл), который легко разворачивается и выполняется.
  • Контрольные примеры выглядят как рабочий код и могут использовать те же Java bean-компоненты, которые используются в качестве фасада для EJB-компонентов.
  • Тесты могут быть автоматизированы с использованием Ant-сценария.

Пример использования JUnit и JUnitEE для модульного тестирования

В данном разделе предоставляется пример того, как можно воспользоваться преимуществами интегрированных сред тестирования JUnit и JUnitEE для модульного тестирования простого несохраняющего состояния сессионного EJB-компонента, разработанного в Rational Application Developer IDE. EJB просто добавляет два числа и возвращает их сумму. Тривиальная функция, но она, тем не менее, содержит все необходимое для иллюстрации этого примера. В третьей части данной серии статей в пошаговом режиме описывается процесс создания и модульного тестирования EJB-компонентов в программе Rational Application Developer.

Для простоты данный пример представляет собой модульный тест несохраняющего состояние сессионного компонента. Однако вы можете использовать также и другие типы EJB-компонентов, используя интегрированные среды JUnit и JUnitEE. Примененный здесь упрощенный подход включает следующие действия:

  1. Создать простой калькулятор в виде Java bean-компонента.
  2. Создать EJB для базового калькулятора.
  3. Сгенерировать EJB-клиент.
  4. Разработать контрольные примеры JUnit для тестирования как Java-приложения, так и EJB-компонента калькулятора.
  5. Создать и настроить тестовый модуль JUnitEE.
  6. Развернуть и выполнить контрольные примеры в среде WebSphere Application Server.

Вы можете загрузить исходный код всех примеров данной статьи (см. раздел "Ресурсы").

Шаг 1. Создать простой калькулятор в виде Java bean-компонента

Первый пример - это простое Java-приложение, складывающее два числа и возвращающее их сумму. В листинге 2 показана реализация класса.

Листинг 2. Реализация Basic Calculator Java Bean
package calc;

public class BasicCalculator {

   public double addTwoNumbers(double first, double second) {
	return first + second;
   }
}

Шаг 2. Создать EJB-компонент для базового калькулятора

Используйте Rational Application Developer для генерирования несохраняющего состояния сессионного компонента под названием BasicCalculator.

В листинге 3 содержится пример того, как может выглядеть EJB-компонент.

EJB-класс BasicCalculatorBean содержит один бизнес-метод, addTwoNumbers, для функции калькулятора. Этот бизнес-метод добавляется в удаленный интерфейс для предоставления клиентам доступа к нему. EJB-компоненты могут быть удаленными, распределенными объектами. Rational Application Developer IDE генерирует клиентские артефакты для легкого доступа к удаленным объектам. Тестовое приложение может находиться в отдельном EAR-архиве (Enterprise Archive), поэтому мы используем удаленные, а не локальные интерфейсы к EJB (в третьей части данной серии статей показано, как создать клиентские артефакты, используя интеллектуальные подсказки IDE).

Листинг 3. Реализация Basic Calculator EJB
package ejbs;
/**
 * Класс реализации bean-компонента для Enterprise Bean: BasicCalculator
 */
public class BasicCalculatorBean implements javax.ejb.SessionBean {
	private javax.ejb.SessionContext mySessionCtx;

	public javax.ejb.SessionContext getSessionContext() {
		return mySessionCtx;
	}
	public void setSessionContext(javax.ejb.SessionContext ctx) {
		mySessionCtx = ctx;
	}
	public void ejbCreate() throws javax.ejb.CreateException {
	}
	public void ejbActivate() {
	}
	public void ejbPassivate() {
	}
	public void ejbRemove() {
	}
	
	public double addTwoNumbers(double first, double second) {
		return first + second;
	}
	
}

Шаг 3. Генерирование EJB-клиента

На данном шаге следуйте за интеллектуальными подсказками Rational Application Developer для генерирования клиентских артефактов. Эти действия будут продемонстрированы в третьей части данной серии статей.

Шаг 4. Разработайте контрольные примеры JUnit для тестирования Java и EJB-компонента калькулятора

После реализации Java Bean Calculator, Basic Calculator EJB и EJB-клиента можно приступить к написанию контрольных примеров JUnit.

Модульное тестирование Java-приложения с использованием JUnit
Здесь вы воспользуетесь преимуществами структуры JUnit-теста, выделенной в листинге 1, для написания трех тестовых методов модульного тестирования BasicCalulator Java Bean и EJB.

Модульные тесты в листинге 4 демонстрируют различные assert-методы для выполнения положительного и отрицательного модульного тестирования. В нем приведены следующие тестовые методы:

  • Метод testSimpleAddition() содержит два утверждения. Первое утверждает, что объект экземпляра калькулятора не равен null, то есть существует. Второе проверяет правильность суммирования калькулятором чисел 2 и 2, сравнивая результат с ожидаемым значением 4.
  • Метод testSimpleAdditionNotSame() демонстрирует отрицательное тестирование для проверки того, что два значения не одинаковы. То есть, сумма чисел (2+2) не равна 5.
  • Метод testDesignedToFail() демонстрирует, как выглядит неудачный контрольный пример в среде JUnitEE. В данном контрольном примере суммируются два аргумента 1 и 1 в BasicCalculator, а затем результат сравнивается со значением 3. Этот тест завершается неудачей. Выводимая информации точно показывает, где и почему произошла ошибка.
Листинг 4. JUnit Test для Calc Java Bean
package calc.test;

import calc.BasicCalculator;
import junit.framework.TestCase;


public class BasicCalculatorTest extends TestCase {

	BasicCalculator aBasicCalculator = null;

	/*
	 * Настройка перед каждым контрольным примером
	 */
	protected void setUp() throws Exception {
		super.setUp();
		aBasicCalculator = new BasicCalculator();
	}
	public void testSimpleAdditionNotSame() throws Exception {

		double result = aBasicCalculator.addTwoNumbers(2, 2);
		assertNotSame("2+2 does not = 5", new Double(result), new Double(5));
	}

	public void testDesignedToFail() throws Exception {
		double result = aBasicCalculator.addTwoNumbers(1, 1);
		assertTrue("1 + 1 = 3", result == 3);

	}
	
	public void testSimpleAddition() throws Exception {

		assertTrue("Calculator instance is not null", aBasicCalculator != null);

		double result = aBasicCalculator.addTwoNumbers(2, 2);
		assertTrue("2+2=4", result == 4);

	}
}
Листинг 5. Исходный код JUnit для тестирования Basic Calculator EJB
package calculator.test;

import java.rmi.RemoteException;
import com.ibm.etools.service.locator.
ServiceLocatorManager;

import ejbs.BasicCalculator;
import ejbs.BasicCalculatorHome;
import junit.framework.TestCase;

public class BasicCalculatorTest extends TestCase {

    BasicCalculator aBasicCalculator = null;

       /*
        * Настройка перед каждым контрольным примером
        */
	protected void setUp() throws Exception {
		super.setUp();
		aBasicCalculator = createBasicCalculator();
	}

	protected void tearDown() throws Exception {
		aBasicCalculator = null;
	}

	public void testSimpleAddition() throws Exception {

		assertTrue("Calculator instance is not null", 
		aBasicCalculator != null);

		double result = aBasicCalculator.addTwoNumbers(2, 2);
		assertTrue("2+2=4", result == 4);

	}

	public void testSimpleAdditionNotSame() throws Exception {

		double result = aBasicCalculator.addTwoNumbers(2, 2);
		assertNotSame("2+2 does not = 5", new
		 Double(result), new Double(5));
	}

	public void testDesignedToFail() throws Exception {

		double result = aBasicCalculator.addTwoNumbers(1, 1);
		assertTrue("1 + 1 = 3", result == 3);

	} /*
	   * Сгенерированный в Rational фрагмент 
	   кода для доступа к EJB
	   */

	private BasicCalculator createBasicCalculator() {

		BasicCalculatorHome aBasicCalculatorHome = 
(BasicCalculatorHome) ServiceLocatorManager
				.getRemoteHome(STATIC_Basic
				CalculatorHome_REF_NAME,
						STATIC_BasicCalculatorHome_CLASS);
		try {
			if (aBasicCalculatorHome != null) {
				return aBasicCalculatorHome.create();
			}
		} catch (javax.ejb.CreateException ce) {
			ce.printStackTrace();
		} catch (RemoteException re) {
			re.printStackTrace();
		}
		return null;
	}

	private final static String STATIC_BasicCalculatorHome_
	REF_NAME = "ejb/BasicCalculator";

	private final static Class STATIC_BasicCalculatorHome_
	CLASS = BasicCalculatorHome.class;
}

Модульное тестирование EJB-компонентов с использованием JUnit
Поскольку EJB-компоненты управляются своими контейнерами, их нужно искать в JNDI-каталоге. Модульное тестирование может быть трудоемким и сложным процессом. К счастью, Rational Application Developer предоставляет фрагменты кода, создающего EJB-экземпляр для разработчика.

Методы calculator несохраняющего состояния сессионного EJB-компонента аналогичны реализации Java bean-компонента. Следовательно, вы можете повторно использовать для ваших модульных тестов EJB контрольные примеры JUnit. Но необходимо сделать несколько изменений в методе setup() для обнаружения и создания экземпляра EJB-объекта. Вспомните, что целью метода setup() является инициализация тестируемого объекта. В этом методе производится вызов createBasicCalculator(), возвращающего EJB-экземпляр калькулятора. Код в этом методе был сгенерирован Rational Application Developer. Метод показан в листинге 6.

Листинг 6. Обнаружение и доступ к home-методу EJB-компонента
private BasicCalculator createBasicCalculator() {

		BasicCalculatorHome aBasicCalculatorHome = 
(BasicCalculatorHome) ServiceLocatorManager
				.getRemoteHome(STATIC_
				BasicCalculatorHome_REF_NAME,
						STATIC_BasicCalculatorHome_CLASS);
		try {
			if (aBasicCalculatorHome != null) {
				return aBasicCalculatorHome.create();
			}
		} catch (javax.ejb.CreateException ce) {
			ce.printStackTrace();
		} catch (RemoteException re) {
			re.printStackTrace();
		}
		return null;
	}

	private final static String STATIC_BasicCalculatorHome_
	REF_NAME = "ejb/BasicCalculator";

	private final static Class STATIC_BasicCalculatorHome_
	CLASS = BasicCalculatorHome.class;
}

Шаг 5. Создайте и настройте тестовый модуль JUnitEE

Для выполнения контрольных примеров JUnit в программной среде WebSphere Application Server можно воспользоваться преимуществами интегрированной среды JUnitEE. Как упоминалось ранее, JUnitEE - это расширение интегрированной среды тестирования JUnit, выполняющее тесты на сервере приложений и использующее интерфейс TestRunner для отображения результатов тестирования в формате HTML или XML. В данном разделе рассказывается, как использовать обе среды тестирования вместе для создания одного развертываемого Web-архива (WAR), содержащего ваши тесты и сервлет JUnitEE для запуска ваших Java и EJB модульных контрольных примеров.

Создание и настройка тестового модуля JUnitEE в программе Rational Application Developer представляет собой интуитивный процесс.

  1. Прежде всего, создайте динамический Web-проект в Rational Application Developer под названием BasicAddJUnitEEWeb.
  2. Поместите файлы junit.jar и junitee.jar в classpath проекта, скопировав их в каталог WEB-INF/lib Web-проекта.
  3. Создайте jar-файл с именем BasicAddUnitTest.jar, содержащий два класса TestCase. Скопируйте jar-файл BasicAddUnitTest.jar в каталог WEB-INF/lib.
  4. Включите XML-код, приведенный в листинге 7, в дескриптор развертывания web.xml.
Листинг 7. Отображение тестового сервлета JUnitEE в дескрипторе развертывания web.xml
1.	<servlet>
2.	  <servlet-name>JUnitEEServlet</servlet-name>
3.	  <display-name>JUnitEEServlet</display-name>
4.	    <servlet-class>org.junitee.servlet.JUnitEEServlet
5.	    </servlet-class>
6.	  <init-param>
7.	      <param-name>searchResources</param-name>
8.	      <param-value>BasicAddUnitTest.jar</param-value>
     </init-param>
9.	</servlet>
10.	<servlet-mapping>
11.	   <servlet-name>JUnitEEServlet</servlet-name>
12.	    <url-pattern>/TestServlet/*</url-pattern>
       </servlet-mapping>

Контрольные примеры JunitEE могут быть выполнены с использованием интеллектуального (smart mode) или базового (basic mode) режима в среде сервера приложений. При использовании интеллектуального режима JUnitEE TestRunner автоматически обнаруживает все тестовые классы, имя которых заканчивается словом "Test" или "Tests", и выполняет их. Интеллектуальный режим настраивается путем указания имени JAR-файла в дескрипторе развертывания, как сделано в листинге 7 в строках 6-8. Если имеется более одного JAR-файла, разделите их запятой. Во время инициализации сервлета контейнер активизирует его, вызывая один раз метод init. Имя параметра searchResources объявляется в строке 7, а в строке 8 этому параметру присваивается значение BasicAddUnitTest.jar. В результате, когда бы контейнер ни активизировал JunitEEServlet, JUnitEE ищет все тестовые классы в файле BasicAddUnitTest.jar.

Альтернативой интеллектуальному режиму служит базовый тестовый режим. В базовом тестовом режиме TestRunner выполняет только тестовые классы, указанные в файле WEB-INF/testCase.txt, который представляет собой простой файл, содержащий одно имя тестового класса JUnit в каждой строке, как показано в листинге 8.

Листинг 8. Текстовый файл с пакетом JUnit-теста и именами классов
com.ibm.junitee.sample.operation.test.BasicAddJavaTest
com.ibm.junitee.sample.operation.test.BasicAddEJBTest

На последнем шаге перед развертыванием убедитесь, что указаны путь компоновки (build path) и все JAR-зависимости. Кроме того, удостоверьтесь, что EAR-файл содержит все необходимые вспомогательные JAR-файлы, а также JUnitEE Web-модуль, спакетированный в WAR-файле. После этого переходите к следующему разделу для развертывания ваших тестов в среде сервера WebSphere Application Server.

Шаг 6. Разверните и выполните контрольные примеры в WebSphere Application Server

На данный момент вы завершили всю подготовительную работу и имеете EAR-файл, содержащий настроенный и спакетированный тестовый модуль JUnitEE (в виде WAR-файла). Развертывание EAR-файла в Rational Application Developer IDE тоже является интуитивным процессом. Мы рассмотрим его в пошаговом режиме в третьей части данной серии статей.

После развертывания EAR-файла на сервере приложений запустите браузер и перейдите по URL JUnitEE-сервлета. Формат этого URL такой: http://<hostname>:<portnumber>/BasicAddJUnitEEWeb/TestServlet, где BasicAddJUnitEEWeb - это имя Web-контекста, имя динамического Web-проекта и TestServlet - это JUnitEE TestRunner-сервлет. В данном примере используется URL http://localhost:9080/BasicAddJUnitEEWeb/TestServlet. На рисунке 1 показана схема процесса обмена данными между J2EE-компонентами.

Рисунок 1. Взаимодействие компонентов
Рисунок 1. Взаимодействие компонентов

При успешном выполнении все тесты отображаются в виде JUnitEE TestRunner, как показано на рисунке 2. На экране отображаются различные способы выполнения вашего модульного теста. Выберите вариант желаемого теста или введите имя вашего тестового набора в поле, предназначенном для запуска контрольных примеров.

Рисунок 2. Экран JUnitEE TestRunner
Рисунок 2. Экран JUnitEE TestRunner

Если нет ошибок в конфигурациях или при поиске JNDI-имени, исполнитель теста (test runner) выполняет выбранные тесты и отображает их результат в окне JUnit Test Results. Этот вид предоставляет исчерпывающую информацию по выполняемым тестам. Если тест выполняется успешно, он отмечается зеленой галочкой. Если тест неудачен, он отмечается красным знаком X. При нажатии на X предоставляется информация трассировки стека для отладки. Мы преднамеренно вызвали неудачное завершение одного из тестов, чтобы продемонстрировать отображение в JUnit неудачных тестов (см. рисунок 3).

Рисунок 3. Вид в JUnit Test Results неудачного теста
Рисунок 3. Вид в JUnit Test Results неудачного теста

Резюме

Примеры в этой статье демонстрируют, как можно быстро и просто разработать, настроить и выполнить модульные тесты Java- и EJB-приложений, используя технологии IBM и интегрированные среды тестирования с открытыми исходными кодами JUnit и JUnitEE для создания безошибочных, высококачественных J2EE-приложений.


Загрузка

ОписаниеИмяРазмер
Пример кодаsourceCode.zip256 KB

Ресурсы

Научиться

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

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=216876
ArticleTitle=Модульное тестирование компонентов J2EE-платформы: Часть 1. Модульное тестирование Java- и EJB-приложений
publish-date=05032007