А по теме:
Вы писали: «Хотя следует отметить наличие опыта работы на PHP и некоторое владение MySQL. Можно сказать, эффект второй системы в действии.»
Эффект второй системы это несколько другая штука, и не совсем корректно применять его в данном контексте.
Вот научишь на свою голову, а потом тебя «уйдут» :) Хотя можно сказать, что хороший специалист нужен всем, но стресс от смены работы ты никуда не денешь :(
А если нет желания учить? Я знаю одного очень неплохого разработчика, который никого не учит. Проблему решить поможет, но не больше. И таких людей много.
Кстати еще один пример, есть знакомый преподаватель который устал учить студентов. У него есть неплохой опыт разработки, но ему надоело передавать данный опыт студентам. Выхлоп очень маленький. Но это наверное проблема высшего образования в РФ и к теме отношения не имеет :)
Сам же я люблю учить людей, есть даже пара человек которыми я могу гордится :) Но все равно очень сложно правильно найти падавана :(
Немного офтопа о развитии:
А есть ли стимул у разработчиков учить студентов жизни? Зачем плодить себе конкурентов?
Есть правда от обучения один плюс, сам начинаешь понимать что пытаешься проповедовать :) Но то не всегда работает :(
Кстати, есть такая биржа удаленной работы odesk. Там когда исполнитель начинает работу на заказчика, запускает специальную программу для мониторинга активности (скриншоты, снимки с веб камеры).
Плохо не наблюдать, плохо делать неправильные выводы из таких наблюдений.
К примеру, есть у меня одна знакомая компания программистов, в которой повсеместно используется система мониторинга рабочего времени (скриншоты, активность, отработанное время).
И все было бы хорошо, но в связи с недостаточным количеством заказов руководство начало «охоту на ведьм».
Теперь проверяется что человек находится на работе 40 часов в неделю и также изучаются его скриншоты.
И на основе полученных данных происходит «направление на путь истинный».
Мотивация пала ниже плинтуса, и уже есть «бежавшие с корабля».
И напоследок две цитаты:
1. Из человеческого фактора: Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
2. Из мифического месяца: В неопубликованном исследовании 1964 года, которое провел E.F. Bardain, показано, программисты продуктивно используют 27% рабочего времени.
Взглянул в скайпе на аватарки знакомых, которые рулят отделами в крупных компаниях. У одного пингвин из Мадагаскара, у другого кот с офигевшим видом, у третьего рисованный перс с электрогитарой:)
Согласен, аннотациями удобнее. Но стояла задача: в одном тесте запускать несколько транзакций. Возможно это можно сделать вызывая в тесте два метода, у каждого из которых аннотация @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
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.
А по теме:
Вы писали: «Хотя следует отметить наличие опыта работы на PHP и некоторое владение MySQL. Можно сказать, эффект второй системы в действии.»
Эффект второй системы это несколько другая штука, и не совсем корректно применять его в данном контексте.
Желаю побольше таких студентов :)
Кстати еще один пример, есть знакомый преподаватель который устал учить студентов. У него есть неплохой опыт разработки, но ему надоело передавать данный опыт студентам. Выхлоп очень маленький. Но это наверное проблема высшего образования в РФ и к теме отношения не имеет :)
Сам же я люблю учить людей, есть даже пара человек которыми я могу гордится :) Но все равно очень сложно правильно найти падавана :(
А есть ли стимул у разработчиков учить студентов жизни? Зачем плодить себе конкурентов?
Есть правда от обучения один плюс, сам начинаешь понимать что пытаешься проповедовать :) Но то не всегда работает :(
Кстати, товарищ голодный, а почему ссылок нет на: yakov-sirotkin.livejournal.com/121661.html и yakov-sirotkin.livejournal.com/121525.html
А то очень уж ваши идеи коррелируют с идеями Якова и с обсуждением их ;)
К примеру, есть у меня одна знакомая компания программистов, в которой повсеместно используется система мониторинга рабочего времени (скриншоты, активность, отработанное время).
И все было бы хорошо, но в связи с недостаточным количеством заказов руководство начало «охоту на ведьм».
Теперь проверяется что человек находится на работе 40 часов в неделю и также изучаются его скриншоты.
И на основе полученных данных происходит «направление на путь истинный».
Мотивация пала ниже плинтуса, и уже есть «бежавшие с корабля».
И напоследок две цитаты:
1. Из человеческого фактора: Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
2. Из мифического месяца: В неопубликованном исследовании 1964 года, которое провел E.F. Bardain, показано, программисты продуктивно используют 27% рабочего времени.
А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — 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
Самое главное без фанатизма, разработка некоторых тестов нерациональна и алогична.