Взглянул в скайпе на аватарки знакомых, которые рулят отделами в крупных компаниях. У одного пингвин из Мадагаскара, у другого кот с офигевшим видом, у третьего рисованный перс с электрогитарой:)
Согласен, аннотациями удобнее. Но стояла задача: в одном тесте запускать несколько транзакций. Возможно это можно сделать вызывая в тесте два метода, у каждого из которых аннотация @Tranactional, но у меня это почему то не заработало. Так оказалось проще.
Использование правил конверсии наверное в Fasade. Поэтому если использование правил конверсии сложная штука, то заменяем дао на моки:)
Тут ведь главное без фанатизма, чтобы не было тестов ради тестов:)
Помнится был у меня один проект, где приходилось модель данных преобразовывать в модель данных вебсервиса (AXIS). Так вот, я там писал тесты по преобразованию AXIS модели в обычную модель. Тут наверное тоже можно было попробовать написать тесты для правил конверсии. Причем эти тесты очень хорошо дополнили бы интеграционные тесты:)
Ну не скажите, порой без юнит-тестов очень сложно жить. Для получения пользы от них надо расслаивать систему (повышать связность и понижать сцепление). И тогда будет вам счастье, когда у вас есть отдельные части системы, которые легко тестировать, тогда очень сильно возрастает уверенность в коде.
По поводу вашего случая: скорее всего у вас на сервере был только интерфейс для доступа данных, вся бизнес-логика была на flex-клиенте (возможно у вас даже было смешение бизнес-логики и представления данных). Если так, то тогда действительно вам юнит тесты особо не требуются, хотя может быть стоит тестировать flex-приложение? Также остается открытым вопрос об объеме передаваемых по сети данных и сложности поддержки flex-приложения:)
Кстати, а можно поподробнее про архитектуру вашего приложения, просто любопытно:)
У нас DAO классы обычно содержат код для получения данных из БД и простейшего преобразования их. Например вернуть map или set по результатам выполнения запросов. Поэтому их тестировать особого смысла нет, там слишком простой код. Хотя иногда тестирование сложных select или update запросов требуется.
В свою очередь services обычно содержит сложную логику преобразования одно объектной модели в другую (обработка и расчет исходных данных). Поэтому их тестировать надо, и лучше всего это делать так как уже говорил выше victorb (http://habrahabr.ru/blogs/java/70168/#comment_2003211). То есть создавая объекты заглушки для остального окружения. Например, при тестировании сервиса считается что остальное окружение работает предсказуемо и в нем нет ошибок о которых мы не знаем. Для создания объектов-заглушек мы используем EasyMock.
А тесты описанные в посте требуются для оценки работоспособности: Services -> DAO -> БД. Они интеграционные и их обычно не так много как обычных юнит-тестов.
p/s
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.
1. Наследование в тестах сложилось исторически :) Возможно в следующем проекте вместо наследования будет аннотация RunWith junit.org/apidocs/org/junit/runner/RunWith.html
2. Конфигурационный файл для hibernate нужен для JBossTools и liquibase :)
А мобильные устройства (браузеры в мобильных устройствах) поддерживают сжатие трафика? Если да, то тогда возникает вопрос: сколько это съедает процессорного времени. А в мобильных устройствах железо не очень мощное:)
То есть вы пошли путем создания жесткого фреймворка? Это когда разработчику дается только один рекомендованый путь:)
Интересно было бы услышать про хаки в класслоадерах:)
p/s
Я не сильно наглею?:)
Я ждал этого ответа:)
Просто я тоже учавствовал в разработке веб-фреймворка где была динамическая подгрузка модулей. Решение добавить динамику привело к усложнению поддержки, да и в итоге все выродилось в: выложил новый модуль, перезапустил сервер приложений:)
2. А в какой области вы расширили манифесты? Чего не хватило в стандартном OSGi?
3. Интересно было бы знать нагрузку на сервер. Сколько у вас одновременно работающих пользователей?
Кстати я немного слукавил, с вашей системой (наумен кернел) мне уже приходилось сталкиваться два года назад. Судя по всему у вас больших изменений так и не случилось:) Зато стабильность наверно возросла в разы:)
А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — fprog.ru/2009/issue1/eugene-kirpichev-fighting-mutable-state/
Согласен, аннотациями удобнее. Но стояла задача: в одном тесте запускать несколько транзакций. Возможно это можно сделать вызывая в тесте два метода, у каждого из которых аннотация @Tranactional, но у меня это почему то не заработало. Так оказалось проще.
Тут ведь главное без фанатизма, чтобы не было тестов ради тестов:)
Итого: (все) больше чем (знающие) больше чем (понимающие).
По поводу вашего случая: скорее всего у вас на сервере был только интерфейс для доступа данных, вся бизнес-логика была на flex-клиенте (возможно у вас даже было смешение бизнес-логики и представления данных). Если так, то тогда действительно вам юнит тесты особо не требуются, хотя может быть стоит тестировать flex-приложение? Также остается открытым вопрос об объеме передаваемых по сети данных и сложности поддержки flex-приложения:)
Кстати, а можно поподробнее про архитектуру вашего приложения, просто любопытно:)
В свою очередь services обычно содержит сложную логику преобразования одно объектной модели в другую (обработка и расчет исходных данных). Поэтому их тестировать надо, и лучше всего это делать так как уже говорил выше victorb (http://habrahabr.ru/blogs/java/70168/#comment_2003211). То есть создавая объекты заглушки для остального окружения. Например, при тестировании сервиса считается что остальное окружение работает предсказуемо и в нем нет ошибок о которых мы не знаем. Для создания объектов-заглушек мы используем EasyMock.
А тесты описанные в посте требуются для оценки работоспособности: Services -> DAO -> БД. Они интеграционные и их обычно не так много как обычных юнит-тестов.
p/s
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.
p/s
Кому ночь, а кому на работе быть через полтора часа:)
Только иногда требуется несколько транзакций в тесте:)
2. Конфигурационный файл для hibernate нужен для JBossTools и liquibase :)
p/s
Может пора железо обновлять…
Интересно было бы услышать про хаки в класслоадерах:)
p/s
Я не сильно наглею?:)
Просто я тоже учавствовал в разработке веб-фреймворка где была динамическая подгрузка модулей. Решение добавить динамику привело к усложнению поддержки, да и в итоге все выродилось в: выложил новый модуль, перезапустил сервер приложений:)
Продолжим?;)
2. А в какой области вы расширили манифесты? Чего не хватило в стандартном OSGi?
3. Интересно было бы знать нагрузку на сервер. Сколько у вас одновременно работающих пользователей?
Кстати я немного слукавил, с вашей системой (наумен кернел) мне уже приходилось сталкиваться два года назад. Судя по всему у вас больших изменений так и не случилось:) Зато стабильность наверно возросла в разы:)