Hypersonic — это и есть hsqldb (Hypersonic SQL DB)… И именно in-memory.
Есть у нас группа тестов (небольшая), которая соединяется с тестовым сервером и делает несколько проверок, только чтобы убедиться, что новый код попал на тестовый сервер, миграция базы данных прошла успешно, и т.д.
>— с утра делаешь update (или pull), прогоняешь тесты и садишься дальше писать с душевным спокойствием, что все работает как должно
А вот тут позвольте с вами не согласиться :) Я стараюсь оставить какой-нибудь тест сломанным на ночь. Тогда с утра легче раскачаться, особенно, если примерно знаешь, что поломано и как починить.
Или еще пример — как без нормальных тестов можно сливать свой код с чьим-то (если в команде 2 и больше программистов)? У меня что, голова безразмерная — думать обо всех глупостях, которые придут в голову очередному гению? А так я просто делаю git pull; mvn clean install — и все. А уж потом, в конце дня — code review, чтобы ручки шаловливые пообломать, если понадобится.
Пардон, наврал. Мы еще активно используем doWithTransaction(TransactionCallback). В лучших традициях Spring-а у нас транзакции объявлены только вокруг методов из сервисов. Поэтому иногда в тестах нужно вручную обернуть какие-то вызовы в транзакции (например, вызовы методов из Repository). Тоже не сложно написать самому и использовать с любыми базовыми классами для тестов. хоть Spring-овыми, хоть какими.
Если совсем честно, из ORMUnit мы реально используем только код, который пересоздает базу. Посмотрите исходники, написать этот кусок самому — нечего делать: Вот тут все написано
Не совсем под каждый тест. Spring context создается под каждый тестовый класс. Перед каждым тестом (в setUp() абстрактного родительского теста) через ORMUnit находится LocalSessionFactoryBean (из Hibernate), и на нем делается dropDatabaseSchema(); createDatabaseSchema();.
Тут есть возможности для улучшения. В большом числе случаев достаточно создать Spring context один раз для всех тестов, которые наследуют от какого-то корня. Но во времена оны (когда писался ORMUnit), JUnit4 и TestNG не существовало еще, и поэтому нельзя было без танцев с бубном сделать @BeforeSuite. Теперь можно. Надо бы взять ORMUnit и переписать для использования с JUnit4.
А так — да, ORMUnit мы используем до сих пор. Единственная проблема — он заставляет использовать JUnit 3. Но это не очень большая проблема.
Спасибо! Я действительно люблю писать тесты к своему коду. Я по жизни — существо достаточно безалаберное, и с начала своей карьеры программиста всегда с завистью смотрел на «крутых спецов», которые открывают на экране сразу пять окон vi, держат все в голове, пишут код, который сразу работает. А когда я открыл для себя тесты, я обнаружил, что этого всего не нужно, чтобы быть хорошим спецом. Достаточно написать пару тестов, и они гарантируют, что твой код не сломается в самый ответственный (или позорный) момент. Можно написать тест прямо по техзаданию и иметь возможность доказать, что это не моя проблема, а проблема проектировщика, писавшего техзадание. Можно не держать все детали всех сотен классов в голове, а в любой момент посмотреть, что каждый из них должен делать в какой момент. Короче, без них я бы не имел никакой возможности сойти за крутого :) Плюс у тестов (особенно, integration тестов) есть такая особенность, что они часто показывают проблемы за пределами того, что они проверяют. На последнем проекте гигансткое количество мелких огрешностей с Hibernate маппингами было отловлено в процессе написания end-to-end тестов — то есть тестирования всего приложения, а не отдельных модулей. Причем такие вещи всплывали, что их и не догадаешься специально тестировать.
Короче, без тестов я бы никогда не смог отвечать за свой код и код своей команды. И спать спокойно в ночь, когда наш продукт устанавливался у клиента (я реально спал, и начальству написал, что, мол, разбудите, если что, но я думаю, что не понадобится. И не понадобилось, что мне очков прибавило).
Но если писать с нуля и одновременно код и тесты, то это не только возможно, но и желательно.
В моем последнем проекте лично мы написали около 200000 строк кода, покрытие тестами колебалось между 75 и 85 процентами. Не было тестов на всяки геттеры/сеттеры и прочий boilerplate код. Я поспорил с менеджером на обед, что профессиональные QA не найдут багов, и выиграл (они, конечно, нашли, но это были проблемы с юзабилити и не до конца ясными требованиями. Наш код работал.)
Неофитов TestNG хочу предупредить — существует определенный геморрой при запуске тестов TestNG через maven-surefire-plugin. В энторнетах примерно миллион блогов, посвященных этому вопросу, ищите и найдете, какую версию плагина использовать с какой версией TestNG. Ничего фатального, просто некоторые версии этих вещей несовместимы.
За несколько последний лет я убедился, что если какой-то код (или кусок кода) заставляет думать, как же его тестировать, то он неправильно написан*. Вот прямо сейчас я сижу и переделываю чужой код, который плохо тестируется (именно по указанной Вами причине — сложные, разветвленные и зависимые классы).
Каюсь, я не всегда следую правилу «сначала напиши тест, а потом пиши код, пока тест не пройдет», хотя каждый раз убеждаюсь, что сдеать именно так было бы дешевле. Но когда я сталкиваюсь с тем, что мне неочевидно, как тестировать только что написанный кусок, я останавливаюсь и переделываю его.
Прошу мне поверить, что я не упертый пурист и не догматик. Для меня TDD — не догма. Я нормальный инженер, и моя главная задача, чтобы мой код хорошо работал. Просто я много-много раз убеждался, что много хороших тестов — это гарантия того, что код будет работать хорошо и сегодня, и через полгода, и когда угодно. И если его изменить/улучшить, то тесты поймают все потенциальные проблемы, значит лично мне не придется отвлекаться от хабра или чем там я еще буду заниматься, чтобы выискивать баги в старом (или, еще хуже) чужом коде. Поэтому я сам пишу, как минимум, в три раза больше строк кода в тестах, чем в собственно продукте, и от своих орлов требую того же.
К чему я снова принялся доказывать, что тесты — это хорошо? А к тому, что:
1. Тесты — это хорошо
2. Если код нетривиально тестируется, значит, это плохой код, который надо переделать. Почему? См. 1.
*) Исключение составляют куски кода, которые взаимодействуют с внешними вещами — чужой онлайновый сервис, запущенные процессы, и т.д., и т.п. В этом случае тестирование действительно нетривиально, но возможно. Для этого берется самый лучший инженер в команде и он пишет фрейворк для тестирование именно таких кусков (например, собственная имплементация Amazon EC2 API. Или библиотека для запуска и гарантированного уничтожения внешних процессов. Или еще что-нибудь такое же ненужное и громоздкое. Потому что оно нужное. Может быть, самое нужное во всем продукте.
Удивлен, честно. Не встречал ничего подобного ни в одной компании, где работал раньше. Хотя, кроме одной компании в начале карьеры и нынешней, в больших конторах предпочитал не работать. Более того, был знаком с одним человеком из Израиля, который был выслан в 24 часа домой за «свинский мужской шовинизм» — подвез домой коллегу по американскому офису.
Интересно у вас в Израиле. Есть подозрение, что если кому-нибудь в Штатах придет в голову организовать подобный семинар, через 20 минут его голова будет торчать на шесте при входе в HR.
Есть у нас группа тестов (небольшая), которая соединяется с тестовым сервером и делает несколько проверок, только чтобы убедиться, что новый код попал на тестовый сервер, миграция базы данных прошла успешно, и т.д.
А вот тут позвольте с вами не согласиться :) Я стараюсь оставить какой-нибудь тест сломанным на ночь. Тогда с утра легче раскачаться, особенно, если примерно знаешь, что поломано и как починить.
Тут есть возможности для улучшения. В большом числе случаев достаточно создать Spring context один раз для всех тестов, которые наследуют от какого-то корня. Но во времена оны (когда писался ORMUnit), JUnit4 и TestNG не существовало еще, и поэтому нельзя было без танцев с бубном сделать @BeforeSuite. Теперь можно. Надо бы взять ORMUnit и переписать для использования с JUnit4.
А так — да, ORMUnit мы используем до сих пор. Единственная проблема — он заставляет использовать JUnit 3. Но это не очень большая проблема.
Короче, без тестов я бы никогда не смог отвечать за свой код и код своей команды. И спать спокойно в ночь, когда наш продукт устанавливался у клиента (я реально спал, и начальству написал, что, мол, разбудите, если что, но я думаю, что не понадобится. И не понадобилось, что мне очков прибавило).
Но если писать с нуля и одновременно код и тесты, то это не только возможно, но и желательно.
В моем последнем проекте лично мы написали около 200000 строк кода, покрытие тестами колебалось между 75 и 85 процентами. Не было тестов на всяки геттеры/сеттеры и прочий boilerplate код. Я поспорил с менеджером на обед, что профессиональные QA не найдут багов, и выиграл (они, конечно, нашли, но это были проблемы с юзабилити и не до конца ясными требованиями. Наш код работал.)
За несколько последний лет я убедился, что если какой-то код (или кусок кода) заставляет думать, как же его тестировать, то он неправильно написан*. Вот прямо сейчас я сижу и переделываю чужой код, который плохо тестируется (именно по указанной Вами причине — сложные, разветвленные и зависимые классы).
Каюсь, я не всегда следую правилу «сначала напиши тест, а потом пиши код, пока тест не пройдет», хотя каждый раз убеждаюсь, что сдеать именно так было бы дешевле. Но когда я сталкиваюсь с тем, что мне неочевидно, как тестировать только что написанный кусок, я останавливаюсь и переделываю его.
Прошу мне поверить, что я не упертый пурист и не догматик. Для меня TDD — не догма. Я нормальный инженер, и моя главная задача, чтобы мой код хорошо работал. Просто я много-много раз убеждался, что много хороших тестов — это гарантия того, что код будет работать хорошо и сегодня, и через полгода, и когда угодно. И если его изменить/улучшить, то тесты поймают все потенциальные проблемы, значит лично мне не придется отвлекаться от хабра или чем там я еще буду заниматься, чтобы выискивать баги в старом (или, еще хуже) чужом коде. Поэтому я сам пишу, как минимум, в три раза больше строк кода в тестах, чем в собственно продукте, и от своих орлов требую того же.
К чему я снова принялся доказывать, что тесты — это хорошо? А к тому, что:
1. Тесты — это хорошо
2. Если код нетривиально тестируется, значит, это плохой код, который надо переделать. Почему? См. 1.
*) Исключение составляют куски кода, которые взаимодействуют с внешними вещами — чужой онлайновый сервис, запущенные процессы, и т.д., и т.п. В этом случае тестирование действительно нетривиально, но возможно. Для этого берется самый лучший инженер в команде и он пишет фрейворк для тестирование именно таких кусков (например, собственная имплементация Amazon EC2 API. Или библиотека для запуска и гарантированного уничтожения внешних процессов. Или еще что-нибудь такое же ненужное и громоздкое. Потому что оно нужное. Может быть, самое нужное во всем продукте.
Где-то так
(пригибается в страхе)