Тестирование Java EE приложения?

Question

[web_dev]

Здравствуйте,

подскажите пожалуйста поподробней, я так то в гугле покопался, но очень много всего…

Есть проект Java web-project [Spring, JPA, Hibernate, Vaadin].

Как писать тесты под такой проект?
TestNG, JUnit?

Может кто поделится ссылкой или подскажет, где рассматривается простейший пример тестирования такого проекта.(жел на русском)
Ну или в двух словах объяснит.

Спасибо!

Answer 1

[MrMig]

Есть несколько разновидностей тестов. Если вы бэкэнд-разработчик, то вас, в первую очередь, будут интересовать два вида:

1. Юнит-тесты
2. Интеграционные тесты

Юнит-тесты — тесты, направленные на тестирование отдельных частей класса. Чаще всего это методы. Иногда — отдельные ветки методов (всегда справедливо для god objects).
Самый важный пункт: для юнит-тестирования не нужно поднимать контекст приложения! Вы тестируете логику отдельного юнита, а не связку классов. Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

Что покрывается юнит-тестами? В первую очередь покрывайте бизнес-логику (сервисы, классы-менеджеры). После — контроллеры. Можно покрыть DAO-слой (опять же, если там есть сложная логика)0.

Как пишется юнит-тест? Вы берёте набор входных параметров, мокаете классы-зависимости, передаёте входные параметры в тестируемый метод и проверяете выходные параметры. Если в методе есть условия — необходимо попасть во все ветки.

Писать ли отдельный тестовый метод для каждой ветки? Это зависит от вашего стиля и от того, планируете ли вы рефакторинг в ближайшем будущем. По-хорошему, стоит выделять отдельные крупные ветки в отдельные методы, особенно для god objects.

Интеграционные тесты — это тестирование нескольких взаимосвязанных классов. К примеру, класс бизнес-логики + DAO-класс.
В случае интеграционного теста вам придётся поднимать контекст приложения (обычно для этого создаются отдельные конфигурационные файлы). К тому же, будет неплохо настроить транзакционность на уровне отдельных методов (для того, чтобы не чистить базу руками после изменений).

Нужны более глубокие подробности — пишите :)

Comments

[web_dev]

Спасибо за ответ, достаточно. Более глубокие понятия придут(приходят) с опытом. )

Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

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

[MrMig]

Предположим, вы покрываете тестами objA.doJob(entity);
У бина есть два поля — имя и параметр. Метод doJob меняет в переданном бине параметр, но не меняет имя бина. Надо проверить то, что параметр изменён.

Внутри метод doJob() вызывает objB.serviceCall(), который стучится в базу (загружает энтити) или делает вызов на сторонний вебсервис и возвращает энтити бин, который как-то будет влиять на наш переданный entity, и менять в нём параметр.

Смотрите, для того, чтобы не поднимать весь контекст ( и не запускать всю подноготную приложения), вам нужно каким-то образом реализовать «тестовый» класс-зависимость objB (создать mock instance), который бы реально не стучался в базу и не делал вызовов на вебсервис. Вы можете написать самостоятельную реализацию, которая возвращала бы нужный бин (который вы бы создали через конструктор с некими тестовыми параметрами, которые проверяли бы через assertEquals в тесте).
Для того, чтобы не писать шаблонный код, вы используете мок-фрейсворк. Для мокито код будет выглядеть примерно так:

 import static org.mockito.Mockito.*;

// Создаём детерминированный бин, по которому будем делать проверки
// Это то, что якобы должно тянуться из источника данных
EntityBean entity = new EntittyBean("TestName", "Test parameter");

//автоматически создаём мок
ObjB objB = mock(ObjB.class);

//Самый важный вызов - заставляем мок возвращать нам нужный бин при вызове метода serviceCall
when(objB.serviceCall()).thenReturn(entity)

//Создаём реальный инстанс тестируемого класса - чтобы вызывать реальные методы
ObjA objA = new ObjA();

//Инжектируем мок. Я надеюсь, у вас все зависимости не @Autowired private поля без сеттеров? ;)
objA.setObjB(objB);

//Вызываем метод
EntityBean testEntity = new EntityBean("Another name", "Another parameter");
objA.doJob(testEntity);

//По правилам нашего метода, testEntity должен получить параметр из entity
assertEquals(testEntity.getParameter(), entity.getParameter());
// Но имя бина не должно измениться
assertNotEquals(testEntity.getName(), entity.getName());

[web_dev]

Мммммм, очень хорошо и понятно, постараюсь вникать(вникнуть).
Благодарствую, если что, то попробую побеспокоить в этом же вопросе.

Answer 2

[Alex42rus]

У нас тот же стек технологий.
Мы используем обычные юнит тесты + селениум для тестирования GUI

Comments

[web_dev]

Спасибо за ответ.
Ну с GUI пока рановато, интересует первое.
Собственно синтаксис и примеры я смогу посмотреть в гугле. Интересует еще следующее.

Как на счет обычных «Entity»? Для них тоже нужно писать тесты? Я сомневаюсь, но все таки спрошу.

Иии насколько мне кажется если «Entity», то подобные функции должны быть к примеру в dao? Пытаюсь понять — как правильно.

	public Job removeJob(int index) {
		return this.jobs.remove(index);
	}

спасибо.

Answer 3

[web_dev]

Буду признателен так же на ответ из моего комментария на ответ Alex42rus.

Comments

[Arktos]

Как правило, Entity не содержат чего-либо, что есть смысл тестировать. Если какие-то сложные transient-методы, то для них подойдут обычные JUnit тесты. Если hql-методы, то аналогично тестированию dao

[dshvechikov]

часто entity содержат аннотации для валидации, к примеру. Вот можно эту часть тестить — правильный паттерн, не забыли ли никаких проверок на null, не пустое, ну и так далее

[web_dev]

Спасибо

Answer 4

[Arktos]

Интеграционные тесты с Maven, JUnit и Spring

Comments

[web_dev]

Обязательно сейчас же почитаю.

Answer 5

[relgames]

На прошлой работе мы делали юнит и интеграционные тесты. Для юнит-тестов использовали TestNG, для интеграционных — написали свой фреймворк, который эмулировал все подряд. Базу создавали в памяти.

На новой работе используем JUnit и собираемся перевести интеграционные тесты на in-memory базу.