Комментарии 45
НЛО прилетело и опубликовало эту надпись здесь
Каким образом Вы создаете тесты при помощи аннотаций? Наследование от тестовых классов на сколько я помню единственный вариант ИМХО.
Кстати аналогично можно в TestNG транзкациями управлять, только там транзакция начинается перед а
заканчивается после теста.
Кстати аналогично можно в TestNG транзкациями управлять, только там транзакция начинается перед а
заканчивается после теста.
НЛО прилетело и опубликовало эту надпись здесь
Вариант хороший. С Junit давно работал и без аннотаций. *Пошел перечитывать доку* ))
НЛО прилетело и опубликовало эту надпись здесь
Главное не переборщить)). Был случай, когда в bean'ах были аннотации от coherence, json. Код становился просто трудночитаемым, что не очень то и хорошо.
В аннтациях минус в том, что конфигурация по сути расползает по всему коду. Удобны, без вариантов. Но такой моментик есть.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Не понял.
НЛО прилетело и опубликовало эту надпись здесь
Хорошая это какая из трех?
НЛО прилетело и опубликовало эту надпись здесь
А где она показывает в одном месте все Hibernate аннотации?
НЛО прилетело и опубликовало эту надпись здесь
Причем тут я, мне интересно о чем ВЫ говорите. Просто вдруг я какую то клевую фишку IDEA упускаю.
НЛО прилетело и опубликовало эту надпись здесь
Вот те раз, в итоге выходит я еще и не в контексте. Ок, простой пример. Если будем схему маппинга делать через аннотации @Entity, @Column и т.п. то сложно будет увидеть даже банально из коммитов когда изменили маппинг, меняя код, а когда не меняли. Надо каждый файл посмотреть diff. Если же писать самому xml, то правка маппинга отчетливо видна — изменение в xml, ожидай изменения в маппинге. Вот и выходит, что конфигурация расползается по всему коду.
НЛО прилетело и опубликовало эту надпись здесь
Об этом и говорят, что приходится кроме анализа самих изменений маппанга еще и искать ГДЕ они произошли. В случае пары BlaBlaBlaEntity это не сложно, а когда за неделю команда наменяла в коде горы, вы предлагаете просматривать каждый Entity? В случае xml просто делается diff двух ревизий, а в случае аннотаций?
Тут тоже транзакция начинает при начале каждого теста и заканчивается при окончании теста :)
Только иногда требуется несколько транзакций в тесте:)
Только иногда требуется несколько транзакций в тесте:)
1. Наследование в тестах сложилось исторически :) Возможно в следующем проекте вместо наследования будет аннотация RunWith junit.org/apidocs/org/junit/runner/RunWith.html
2. Конфигурационный файл для hibernate нужен для JBossTools и liquibase :)
2. Конфигурационный файл для hibernate нужен для JBossTools и liquibase :)
давно пользуюсь примерно аналогичным окружением. только вместо голого junit, использую связку testng+unitils. позволяет разбивать тесты на группы, и солидно так сокращает код, за счет использования ReflectionAssert и прочих приятностей из unitils.
Спасибо за Unitils! ReflectionAssert, мне очень не хватало.
не за что. еще что хотел сказать по поводу этой статьи — интеграционные тесты со спрингом конечно бывают нужны, но по сути в большинстве случаев лучше изолировать тестируемый код, подставляя вместо зависимостей Mock'и. Которые тоже здорово и просто делать с помощью Unitils. То есть, к примеру, для тестирования сервисов удобно создать mock'и dao и проверять не «во всю глубину», а только контракт взаимодействия сервиса и dao.
а почему спринг не третий?
А как вы думаете — писать такие тесты стоит на уровне DAO или Services? Или и там и там?
У нас DAO классы обычно содержат код для получения данных из БД и простейшего преобразования их. Например вернуть map или set по результатам выполнения запросов. Поэтому их тестировать особого смысла нет, там слишком простой код. Хотя иногда тестирование сложных select или update запросов требуется.
В свою очередь services обычно содержит сложную логику преобразования одно объектной модели в другую (обработка и расчет исходных данных). Поэтому их тестировать надо, и лучше всего это делать так как уже говорил выше victorb (http://habrahabr.ru/blogs/java/70168/#comment_2003211). То есть создавая объекты заглушки для остального окружения. Например, при тестировании сервиса считается что остальное окружение работает предсказуемо и в нем нет ошибок о которых мы не знаем. Для создания объектов-заглушек мы используем EasyMock.
А тесты описанные в посте требуются для оценки работоспособности: Services -> DAO -> БД. Они интеграционные и их обычно не так много как обычных юнит-тестов.
p/s
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.
В свою очередь services обычно содержит сложную логику преобразования одно объектной модели в другую (обработка и расчет исходных данных). Поэтому их тестировать надо, и лучше всего это делать так как уже говорил выше victorb (http://habrahabr.ru/blogs/java/70168/#comment_2003211). То есть создавая объекты заглушки для остального окружения. Например, при тестировании сервиса считается что остальное окружение работает предсказуемо и в нем нет ошибок о которых мы не знаем. Для создания объектов-заглушек мы используем EasyMock.
А тесты описанные в посте требуются для оценки работоспособности: Services -> DAO -> БД. Они интеграционные и их обычно не так много как обычных юнит-тестов.
p/s
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.
Я собственно почему спрашиваю. Был недавно проект — Java на стороне сервера и Flex в качестве клиента.
Схема доступа к данным следующая: DAOServicesDTO Assemblers Facade.
Опыт показывает, что писать тесты на DAO в этом случае — совершенно бесполезно. Т.е. пока не дернуть соответствующий метод фасада — нет никакой гарантии что это будет работать.
И моки на объекты оказались скорее вредны, чем полезны
И действительное положение вещей показывали именно функциональные тесты на фасады
В общем какой-то диссонанс полный с теорией…
Схема доступа к данным следующая: DAOServicesDTO Assemblers Facade.
Опыт показывает, что писать тесты на DAO в этом случае — совершенно бесполезно. Т.е. пока не дернуть соответствующий метод фасада — нет никакой гарантии что это будет работать.
И моки на объекты оказались скорее вредны, чем полезны
И действительное положение вещей показывали именно функциональные тесты на фасады
В общем какой-то диссонанс полный с теорией…
Ну не скажите, порой без юнит-тестов очень сложно жить. Для получения пользы от них надо расслаивать систему (повышать связность и понижать сцепление). И тогда будет вам счастье, когда у вас есть отдельные части системы, которые легко тестировать, тогда очень сильно возрастает уверенность в коде.
По поводу вашего случая: скорее всего у вас на сервере был только интерфейс для доступа данных, вся бизнес-логика была на flex-клиенте (возможно у вас даже было смешение бизнес-логики и представления данных). Если так, то тогда действительно вам юнит тесты особо не требуются, хотя может быть стоит тестировать flex-приложение? Также остается открытым вопрос об объеме передаваемых по сети данных и сложности поддержки flex-приложения:)
Кстати, а можно поподробнее про архитектуру вашего приложения, просто любопытно:)
По поводу вашего случая: скорее всего у вас на сервере был только интерфейс для доступа данных, вся бизнес-логика была на flex-клиенте (возможно у вас даже было смешение бизнес-логики и представления данных). Если так, то тогда действительно вам юнит тесты особо не требуются, хотя может быть стоит тестировать flex-приложение? Также остается открытым вопрос об объеме передаваемых по сети данных и сложности поддержки flex-приложения:)
Кстати, а можно поподробнее про архитектуру вашего приложения, просто любопытно:)
Да архитектура в принципе простая, как всегда.
1. DAO (Hibernate)
2. Services
3. DTO assemblers (жуткий самописный фрамеворк на аннотациях)
4. Facade
Бизнес логики на клиенте не было. Транзакции висели на фасадах.
Самым проблемным был п.3. Было необходимо поддерживать довольно сложные правила конверсии из бизнес-сущностей в DTO и обратно (в том смысле что конверсии одного и того же бина с-клиента и на-клиент чаще всего отличались). Собственно, именно из-за этого я разочаровался во Flex — кажущаяся красивость и простота оборачивается в DTO-hell.
Вот и получилось собственно, что для того, чтобы хоть что-то протестировать надо писать integration тесты для фасадов на реальную базу данных.
1. DAO (Hibernate)
2. Services
3. DTO assemblers (жуткий самописный фрамеворк на аннотациях)
4. Facade
Бизнес логики на клиенте не было. Транзакции висели на фасадах.
Самым проблемным был п.3. Было необходимо поддерживать довольно сложные правила конверсии из бизнес-сущностей в DTO и обратно (в том смысле что конверсии одного и того же бина с-клиента и на-клиент чаще всего отличались). Собственно, именно из-за этого я разочаровался во Flex — кажущаяся красивость и простота оборачивается в DTO-hell.
Вот и получилось собственно, что для того, чтобы хоть что-то протестировать надо писать integration тесты для фасадов на реальную базу данных.
Помнится был у меня один проект, где приходилось модель данных преобразовывать в модель данных вебсервиса (AXIS). Так вот, я там писал тесты по преобразованию AXIS модели в обычную модель. Тут наверное тоже можно было попробовать написать тесты для правил конверсии. Причем эти тесты очень хорошо дополнили бы интеграционные тесты:)
Интересно, а почему 8 минусов за пост? Что не так? Очень бы хотелось негативный отзыв:)
Зачем вы так подробно все описываете где посмотреть? Те, кого интересует тестирование в Spring приложениях подавно знаю что такое Hiberante & Maven & JUnit.
Всегда есть кто то, кто все знает. Но не всегда тот кто знает, тот понимает.
Итого: (все) больше чем (знающие) больше чем (понимающие).
Итого: (все) больше чем (знающие) больше чем (понимающие).
Вроде по делу сказал, а вы тут высокими словами. Сомнительно что кто то рванет изучать всю эту цепочку исключительно чтобы понять статью. Ну и для наглядности прикольней транзакциями рулит через аннтоации. Ну да не надо в пики все воспринимать.
Это же просто ссылки, по ним можно и не ходить:)
Согласен, аннотациями удобнее. Но стояла задача: в одном тесте запускать несколько транзакций. Возможно это можно сделать вызывая в тесте два метода, у каждого из которых аннотация @Tranactional, но у меня это почему то не заработало. Так оказалось проще.
Согласен, аннотациями удобнее. Но стояла задача: в одном тесте запускать несколько транзакций. Возможно это можно сделать вызывая в тесте два метода, у каждого из которых аннотация @Tranactional, но у меня это почему то не заработало. Так оказалось проще.
Но все равно спасибо за почти негативный отзыв. Возможно действительно, чересчур подробно все описано:)
Спасибо за статью.
В вебприложениях DataSource для соединения с БД обычно попадает в applicationConext.xml по средством JNDI, например из META-INF/context.xml для томката.
Поэтому было бы интересно написание подобного теста на базе настоящего applicationConext.xml которому просто подсовывается тестовый DataSource через JNDI.
В вебприложениях DataSource для соединения с БД обычно попадает в applicationConext.xml по средством JNDI, например из META-INF/context.xml для томката.
Поэтому было бы интересно написание подобного теста на базе настоящего applicationConext.xml которому просто подсовывается тестовый DataSource через JNDI.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование Spring приложений. Транзакции в тестировании