Не согласен с автором с тезисом "не ходите дети в тим.лиды". Но мне "не повезло" не поработать в "жабогадюкинских" компаниях. Для меня позиция тим.лида стала ступенькой к "сделать то, что нельзя сделать одному". По этому категорически не согласен.
А если уже по сути, то любая "лидовая" позиция - э то всегда переход в "политику". И здесь я определю "политику", как установление правил. Правил внутри команды. И по описанию автор справился с это задачей хорошо. Правил на "границе" команды. И вот тут автор не справился. Чувствуется отсутствие отсутствие прозрачности с оунером. Из описания складывается впечатления, что не было с ним синков для обсуждения "проблем". Правила "на границе" - это не только "отбивать задачи", это и правила оценки, правила найма и пр.
Наличие правил позволяет лиду(в самом деле это про любую позицию) самому принимать решения - хочет ли он работать с такими правилами - что делать при нарушении этих правил
И мне кажется, что автор "в горячке" просто перестал оценивать ситуацию и не справился с выравниванием ситуации.
Автоматизированное тестирование требует написания кода. А в начинающем продукте надо не просто составлять тест-кейсы из уже написанных шагов, но так писать новые шаги, формировать структуру тестового фреймворка. Что делает работу инженера по тестированию мало отличимой от работы инженера по разработке.
Не каждый инженер по тестированию выдерживал необходимый темп разработки тестов в нашей команде.
Если под хвостами мы понимаем "старые" задачи (которые долго доходили до заказчика), то да количество хвостов сократилось. А так же сократилось общее время поставки, если в конце 24 года (в разных итерациях) 85% задач закрывалось менее чем за 30-40 рабочих дней, то в 25 году эта цифра упала до 15-20 рабочих дней.
С одной стороны соглашусь таска таске рознь. Но мы говорим о числах в районе 200 - 300 задач за полгода. Т.к. команда не меняла правила декомпозиции задач, исполнители те же. То можно считать, что на таком количестве неравность задач усредняется. Т.е. если были бы всплески коротких и длинных задач, то можно было бы говорить о необходимости кластеризации задач на классы обслуживания. Но тут такого не наблюдается.
Если мне зададут вопрос: «Представь, что тебе надо внедрить в команде стори-поинты, что ты будешь делать?»
Я очень сильно подумаю, над предложением от такой компании. В этом вопросе нет проблемы которую должен решить ПМ. Такой вопрос подразумевает ответ: "напишу инструкцию, чтобы все использовали SP".
расширили зону ответственности за написания тестов у разработчиков, да разработчики стали писать больше тестов,
Убрали дублирование тестов на разных уровнях
Эта ситуация показала уровень зрелости команды, когда все члены команды поняли проблему, приняли её и совместно решили. Кадровых изменений в команде в связи с этими изменениями не было.
Мы данную проблему решили исключительно серверными средствами. Мы с сервера для каждого пользователя(после авторизации) выдаём дерево путь->[компонент[->компонент]] и права действия над ними FULL/VIEW. Всё что приходит в дереве, отображается в интерфейсе с пришедшими ограничениями. То, что не пришло в списке разрешённых компонентов не загружается в DOM модель.
Да, это требует синхронизации интерфейса и сервера. Но она и так требуется при появлении нового функционала. Вопрос в том, кто инициатор синхронизации: разработчик клиента, который говорит о новых путях и компонентах в приложении или разработчик бекенда, который говорит о новых действиях.
При этом скрытие элементов или запрет действий на интерфейсе не означает, что проверку прав доступа не надо делать на стороне сервера.
В нашей схеме, к каждому компоненту может быть привязано действие, выполнение которого проверяется уже на стороне сервера, об этой части прав доступа интерфейс не знает вообще ни чего, но на стороне бекенда эти сущности синхронизованы.
Простите, кому продавать то?
Сейчас большинство кандидатов заполняет своё резюме вот таким образом
Компания ХХХХ, (срока работы 3,5 года)
Программист
Разработка и поддержание модулей системы.
Технологиии:
-Х
-У
-Ц
И таких резюме более 90%. С авторами таких резюме вообще не понятно что «не так».
1. Или они о себе мегакрутого мнения, что не снисходят до уровня объяснения, чем они занимались на работе 3 года. Типа я весь из себя мачо, буду выбирать что хочу. Но такие до собеседования со мной не доходили.
2. Либо пофигисты, типа «и так сойдёт». Но этим совсем ни чего не интересно. Они приходя, могут показать разный уровень знаний. Но потом не могут задать ни одного интересующего их вопроса по проекту, по условиям работы. Им и так «всё ясно и понятно».
К сожалению у нас очень низкая культура в этом отношении. Я не уверен, что это проблема страны или сообщества.
И на счёт тестового задания. Если при поиске кандидата начального уровня можно в технической беседе понять, уровень компетенций. То для сеньора всё сложнее. Нужно понять не только как человек может декомпозировать задачу, но и то, как эта декомпозиция будет отражена в коде. И есть ещё один момент тестового задания показывает ответственность кандидата. Может ли он выполнить задачу в оговоренные сроки, может ли озвучить преемлемые сроки решения этой задачи.
Когда я искал работу, мне ни когда не было «сложно» выполнить тестовое задание. Обычно адекватное тестовое задание занимает 2-4-6 чистых часов работы. Это не те затраты которых жалко. Если вакансия интересна, то соглашаешься на тестовое задание, если не интересная — отказываешься. При правильном подходе к поиску работы не может «накопиться» десять тестовых заданий.
Ну с чего же вдруг так? На Java есть высокопроизводительные системы. И качественно работают. На JavaOne ребята выступали, которые на Java писали биржевой аггрегатор.
И ни чего. Работало с нужными им временными задержками. Просто готовить надо уметь.
Нет. Не правильно. В оригинальной статье не говорилось про стрес вызванный посыланием на несколько букв.
Вот отрывок из текущей статьи.
Чем больше ответственность в профессии, тем больше должна быть стрессоустойчивость.
Я работал с продакшен окружением и, бывало, чинил по ночам какие-то проблемы. Зачастую, это был стресс (особенно когда возглавляешь тех отдел и отвечаешь за весь этот колхоз).
И хочу со всей ответственностью заявить: никто не любит стрессы, даже если способен их выдержать. Всегда все стараются сделать так, чтобы стрессов было меньше.
Разговор шёл именно о стрессе, возникающий во время работы в целом. Но большинство почему то решило устроить холивар хороши ли устраивать стресс сотруднику посылая его.
По этому я раздвигал рамки обсуждения до исходных. Но вы их опять пытаетесь сузить до того, как поняли эту статью большинство, что как мне кажется не правильно и не оправданно.
Да, часть стресса может быть из-за того, что тебя отматерили, но потом стресс уже должен возникать из-за того, что ты начинаешь думать, как исправить ситуацию. И у адекватного человека, стресс(в понимании усиленного процесса обдумывания ситуации) из-за решения задачи должен кратно превосходить моральный стресс из-за того, что его послали. При этом так же надо заставить себя подумать, почему же тебя послали, что к этому привело, что так же является стрессом в смысле мыслительной работы головой.
Если бы меня отматерили, то я бы во-первых отсортировал бы «междометия» и выявил бы причину, по которой произошла данная ситуация. Нашёл бы решение для исправления ситуации (возможно два решения, оперативное и стратегическое), после чего я попытался бы отстраниться от причины, и попытался бы понять почему меня именно отматерили (косяк произошёл в «не правильный момент», «косяк произошёл в десятый раз» и т.д.).
Михаил, Вы даже не поняли, что я написал.
Вы сказали, что все горазды подменять понятия через обобщения. И сами сделали обобщение в одном и том же комментарии.
Я вижу, что в холиварах по этой теме народ зарубился, на счёт того, что послать человека на три буквы это стресс, а вот прочитать мануал не является стрессом.
Большинство понимают стресс в усечённом понимании, а именно психологический стресс.
А то, что напряжение мозгов это стрессовая для них работа, не думают. Именно о такого рода стрессе говорил и я и blackisback.
Но все упорно возвращаются к тому, что стресс это исключительно посылание на три буквы.
Меня лично это не проймёт и не станет стрессом.
Если возвращаться, к исходной статье, то посыл был именно в том, что надо давать корректную обратную связь. В первый раз она может быть медовой, а в сотый это может быть и общение в стиле «какого ХХХХ».
Но ни кто почему то не задаётся вопросом, а почему дело дошло до сотого.
Если за короткий промежуток времени дело дошло до сотой обратной связи. То есть несколько вариантов:
1. получатель обратной связи не может её понять ни в какой форме и он не компетентен для задач данного уровня
2. тот кто даёт обратную связь не может найти слова, чтобы сформулировать обратную связь, так, чтобы получатель её понял.
3. Банальный саботаж.
4. что-то ещё…
И это прозрачный намёк, что надо что-то менять, если работник не растёт над уровнем задач.
Да вы что? Вы заметили фразу "всё время". Чтобы не раскрывать карты. Представьте, что вы ищите java-программиста и спрашиваете:
«как устроена строка»?
«сколько байт в типе char»?
Если человек претендующий на должность Senior Java Developer полезит за такими вопросами в Google. То для меня это некомпетентность.
А вопросы были именно такого плана.
Так исходная фраза звучит
Т.е. стресс — это плохо вообще-то
. Где здесь про разные оттенки стресса. Да я понимаю, что стресс он не должен быть постоянный. И более развёрнуто на счёт того, что я имел в виду написал ниже blackisback
У нас уже был использован Thrift для межмодульного взаимодействия. Не хотелось вводить ещё один язык.
Плюс не всегда «слабое развитие» это критический минус. Если продукт решает свои проблемы, и ты не планируешь использовать неподдерживаемые фичи. То это не является критическим местом.
Выбирая из пары развивающихся продуктов, которые только выходят на рынок, тут я соглашусь, что надо смотреть на динамику развития.
В конкретном случае да, нам интересно, чтобы была поддержка транспорта через очереди. Но этого сейчас ни где нет, и пока не предвидеться.
Не знаю, что уважаемый creker подразумевал, что весь транспорт и обвязка пишется руками. Если то, что приходится писать свой сервлет, для работы через http протокол. Или поднимать ручками сервер для работы на сокетах
@Component
class ThriftAdsServer @Autowired constructor(
@Value("\${thrift.server.port}")
private val serverPort: Int,
handler: AdsService.Iface) {
companion object {
private val logger = LoggerFactory.getLogger("THRIFT-SERVER")
}
private val server: TServer
@PostConstruct
fun startServer() {
logger.info("Thrift server starting at port $serverPort")
thread(start = true) {
try {
val serverTransport = TNonblockingServerSocket(serverPort)
server = THsHaServer(THsHaServer.Args(serverTransport).processor(AdsService.Processor(handler)))
server.serve()
} catch (e: Throwable) {
logger.error("Server was crashed.", e)
}
}
}
@PreDestroy
fun stopServer() {
logger.info("Try to stop thrift server serving at port $serverPort")
if (server.isServing) {
server.stop()
logger.info("thrift server was stopped")
} else {
logger.info("Server wasn't started")
}
}
}
То по мне это не большая проблема: написать 40-50 строчек кода для одного сервиса.
Проблема не столько в том, какой набор адаптеров мы выбрали, а в том, что возникают проблемы с синхронизацией серверного и клиентского представления API. Чтобы поддерживать возможность работы команд бекенда и фронтенда независимо друг от друга.
Мы mirage и используем. Дело в том, что при таком подходе для изменения API ты должен вносить несвязанные изменения и на стороне клиента и на стороне сервера. В итоге конфигурация для mirage разрослась. Плюс, как я писал некоторые разработчики меняя модель данных на сервере не всегда меняли модель данных на мираже. Т.е. у нас в mirage есть представление списка сущностей. Список из 20 — 30 записей. И добавление одного поля в данный список приносило много боли.
Когда модель состоит из десятка сущностей — это не очень проблемно, когда количество сущностей кратно возрастает, то возрастает и стоимость «ревью».
Если можно убрать момент «ревью»API, то лучше его убрать.
Писать тесты для выявления ошибок API, это опять вопрос синхронизации. Как можно защититься от того, что разработчик напишет тест только для бекенда, а для «фронтенда» забудет?
Сейчас же с выносом API в единое место, у нас есть гарантия на уровне компиляции, что модели для сервера и клиента будут согласованы. Т.е. во время сборки проекта будет подложена последняя версия API. До этого гарантией служили «соглашения».
Ради интереса на маленьком проекте решил провести небольшой эксперимент.
Изначально на этом проекте тесты написаны над HashMap (эмуляция БД). Т.к. это маленький микросервис, то сложных операций нет: сохранить в таблицу с автоинкрементом, поиск по одному/двум полям. Тесты генерируют малое количество данных, так что такой подход вполне корректен :)
Итак есть отдельный maven модуль, в котором только тесты. Вся бизнес логика в других модулях. Компилирование бизнес-логики в текущих расчётах не учитывается.
В модуле dao объявлено два liqubase changeSet. Добавление таблицы и добавление новых полей в таблицу(эти скрипты естественно не запускаются, если работаю над HashMap).
Есть 5 классов с тестами. Первый класс с пустым тестом, для инициализации SpringContext. В остальных 4х классах 20 тестов. Для каждого варианта делал три запуска тестов. Перед запуском тестов делал mvn clean. Время выполнение брал из логов maven.
Сравнивал, но это было давно, и, естественно, не в пользу postgres.
EmbendedPostgres замедляет работу. Он создаёт новый инстанс на старт нового SpringContext (с запуском всех скриптов обновления). В той же статье, о которой я упомянул было написано, что ребята научились поднимать один инстанс на всю сессию тестов вне зависимости от того, сколько запуститься Spring Context-ов.
Именно по этому мы постепенно мигрируем на «локальные» БД. Это и единичный запуск скриптов обновления или вообще его отсутствие и возможность глазами посмотреть данные в БД. И возможность проверить, как произойдёт накат изменений на существующую структуру данных.
На сервере сборок поднимается Docker-контейнер с Postgres, который потом удаляется тем самым «очищая» результаты работы тестов.
Если Postgres начнёт тормозить, то всегда можно будет настроить RamDisk.
Но если речь про интеграционные тесты, то тут как раз надо проверять интеграцию :) и моменты с БД скрывают не очевидные подводные камни.
Я выше описал, как мы стараемся решать часть проблем с уровнем БД в интеграционных тестах.
Это другого уровня тесты.
1. В современных движках разработки UI есть свои тесты, включая проверку работы компонентов. Это отдельная тема.
2. Тесты на производительность не запускаются один раз. Т.к. производительность, это не одна операция в единицу секунды. А 10^x операций в течении определённого периода времени.
Не согласен с автором с тезисом "не ходите дети в тим.лиды". Но мне "не повезло" не поработать в "жабогадюкинских" компаниях.
Для меня позиция тим.лида стала ступенькой к "сделать то, что нельзя сделать одному". По этому категорически не согласен.
А если уже по сути, то любая "лидовая" позиция - э то всегда переход в "политику". И здесь я определю "политику", как установление правил.
Правил внутри команды. И по описанию автор справился с это задачей хорошо.
Правил на "границе" команды. И вот тут автор не справился. Чувствуется отсутствие отсутствие прозрачности с оунером. Из описания складывается впечатления, что не было с ним синков для обсуждения "проблем".
Правила "на границе" - это не только "отбивать задачи", это и правила оценки, правила найма и пр.
Наличие правил позволяет лиду(в самом деле это про любую позицию) самому принимать решения
- хочет ли он работать с такими правилами
- что делать при нарушении этих правил
И мне кажется, что автор "в горячке" просто перестал оценивать ситуацию и не справился с выравниванием ситуации.
Автоматизированное тестирование требует написания кода. А в начинающем продукте надо не просто составлять тест-кейсы из уже написанных шагов, но так писать новые шаги, формировать структуру тестового фреймворка. Что делает работу инженера по тестированию мало отличимой от работы инженера по разработке.
Не каждый инженер по тестированию выдерживал необходимый темп разработки тестов в нашей команде.
Если под хвостами мы понимаем "старые" задачи (которые долго доходили до заказчика), то да количество хвостов сократилось. А так же сократилось общее время поставки, если в конце 24 года (в разных итерациях) 85% задач закрывалось менее чем за 30-40 рабочих дней, то в 25 году эта цифра упала до 15-20 рабочих дней.
С одной стороны соглашусь таска таске рознь. Но мы говорим о числах в районе 200 - 300 задач за полгода. Т.к. команда не меняла правила декомпозиции задач, исполнители те же. То можно считать, что на таком количестве неравность задач усредняется. Т.е. если были бы всплески коротких и длинных задач, то можно было бы говорить о необходимости кластеризации задач на классы обслуживания. Но тут такого не наблюдается.
Если мне зададут вопрос: «Представь, что тебе надо внедрить в команде стори-поинты, что ты будешь делать?»
Я очень сильно подумаю, над предложением от такой компании. В этом вопросе нет проблемы которую должен решить ПМ. Такой вопрос подразумевает ответ: "напишу инструкцию, чтобы все использовали SP".
Если коротко:
формализовали пирамиду тестирования
расширили зону ответственности за написания тестов у разработчиков, да разработчики стали писать больше тестов,
Убрали дублирование тестов на разных уровнях
Эта ситуация показала уровень зрелости команды, когда все члены команды поняли проблему, приняли её и совместно решили. Кадровых изменений в команде в связи с этими изменениями не было.
Да, это требует синхронизации интерфейса и сервера. Но она и так требуется при появлении нового функционала. Вопрос в том, кто инициатор синхронизации: разработчик клиента, который говорит о новых путях и компонентах в приложении или разработчик бекенда, который говорит о новых действиях.
При этом скрытие элементов или запрет действий на интерфейсе не означает, что проверку прав доступа не надо делать на стороне сервера.
В нашей схеме, к каждому компоненту может быть привязано действие, выполнение которого проверяется уже на стороне сервера, об этой части прав доступа интерфейс не знает вообще ни чего, но на стороне бекенда эти сущности синхронизованы.
Сейчас большинство кандидатов заполняет своё резюме вот таким образом
И таких резюме более 90%. С авторами таких резюме вообще не понятно что «не так».
1. Или они о себе мегакрутого мнения, что не снисходят до уровня объяснения, чем они занимались на работе 3 года. Типа я весь из себя мачо, буду выбирать что хочу. Но такие до собеседования со мной не доходили.
2. Либо пофигисты, типа «и так сойдёт». Но этим совсем ни чего не интересно. Они приходя, могут показать разный уровень знаний. Но потом не могут задать ни одного интересующего их вопроса по проекту, по условиям работы. Им и так «всё ясно и понятно».
К сожалению у нас очень низкая культура в этом отношении. Я не уверен, что это проблема страны или сообщества.
И на счёт тестового задания. Если при поиске кандидата начального уровня можно в технической беседе понять, уровень компетенций. То для сеньора всё сложнее. Нужно понять не только как человек может декомпозировать задачу, но и то, как эта декомпозиция будет отражена в коде. И есть ещё один момент тестового задания показывает ответственность кандидата. Может ли он выполнить задачу в оговоренные сроки, может ли озвучить преемлемые сроки решения этой задачи.
Когда я искал работу, мне ни когда не было «сложно» выполнить тестовое задание. Обычно адекватное тестовое задание занимает 2-4-6 чистых часов работы. Это не те затраты которых жалко. Если вакансия интересна, то соглашаешься на тестовое задание, если не интересная — отказываешься. При правильном подходе к поиску работы не может «накопиться» десять тестовых заданий.
Ну с чего же вдруг так? На Java есть высокопроизводительные системы. И качественно работают. На JavaOne ребята выступали, которые на Java писали биржевой аггрегатор.
И ни чего. Работало с нужными им временными задержками. Просто готовить надо уметь.
Сколько же весят ваши индексы на устройствах?
Привязаны ли они к георгафии пользователя?
Вот отрывок из текущей статьи.
Разговор шёл именно о стрессе, возникающий во время работы в целом. Но большинство почему то решило устроить холивар хороши ли устраивать стресс сотруднику посылая его.
По этому я раздвигал рамки обсуждения до исходных. Но вы их опять пытаетесь сузить до того, как поняли эту статью большинство, что как мне кажется не правильно и не оправданно.
Да, часть стресса может быть из-за того, что тебя отматерили, но потом стресс уже должен возникать из-за того, что ты начинаешь думать, как исправить ситуацию. И у адекватного человека, стресс(в понимании усиленного процесса обдумывания ситуации) из-за решения задачи должен кратно превосходить моральный стресс из-за того, что его послали. При этом так же надо заставить себя подумать, почему же тебя послали, что к этому привело, что так же является стрессом в смысле мыслительной работы головой.
Если бы меня отматерили, то я бы во-первых отсортировал бы «междометия» и выявил бы причину, по которой произошла данная ситуация. Нашёл бы решение для исправления ситуации (возможно два решения, оперативное и стратегическое), после чего я попытался бы отстраниться от причины, и попытался бы понять почему меня именно отматерили (косяк произошёл в «не правильный момент», «косяк произошёл в десятый раз» и т.д.).
Вы сказали, что все горазды подменять понятия через обобщения. И сами сделали обобщение в одном и том же комментарии.
Я вижу, что в холиварах по этой теме народ зарубился, на счёт того, что послать человека на три буквы это стресс, а вот прочитать мануал не является стрессом.
Большинство понимают стресс в усечённом понимании, а именно психологический стресс.
А то, что напряжение мозгов это стрессовая для них работа, не думают. Именно о такого рода стрессе говорил и я и blackisback.
Но все упорно возвращаются к тому, что стресс это исключительно посылание на три буквы.
Меня лично это не проймёт и не станет стрессом.
Если возвращаться, к исходной статье, то посыл был именно в том, что надо давать корректную обратную связь. В первый раз она может быть медовой, а в сотый это может быть и общение в стиле «какого ХХХХ».
Но ни кто почему то не задаётся вопросом, а почему дело дошло до сотого.
Если за короткий промежуток времени дело дошло до сотой обратной связи. То есть несколько вариантов:
1. получатель обратной связи не может её понять ни в какой форме и он не компетентен для задач данного уровня
2. тот кто даёт обратную связь не может найти слова, чтобы сформулировать обратную связь, так, чтобы получатель её понял.
3. Банальный саботаж.
4. что-то ещё…
И это прозрачный намёк, что надо что-то менять, если работник не растёт над уровнем задач.
Вот уж точно
> Херачишь в зале -> подвергаешь мышцы стрессу
> тренер будет вас на 3 буквы посылать? Это стресс же? Стресс.
«как устроена строка»?
«сколько байт в типе char»?
Если человек претендующий на должность Senior Java Developer полезит за такими вопросами в Google. То для меня это некомпетентность.
А вопросы были именно такого плана.
Так исходная фраза звучит
. Где здесь про разные оттенки стресса. Да я понимаю, что стресс он не должен быть постоянный. И более развёрнуто на счёт того, что я имел в виду написал ниже blackisback
Плюс не всегда «слабое развитие» это критический минус. Если продукт решает свои проблемы, и ты не планируешь использовать неподдерживаемые фичи. То это не является критическим местом.
Выбирая из пары развивающихся продуктов, которые только выходят на рынок, тут я соглашусь, что надо смотреть на динамику развития.
В конкретном случае да, нам интересно, чтобы была поддержка транспорта через очереди. Но этого сейчас ни где нет, и пока не предвидеться.
Не знаю, что уважаемый creker подразумевал, что весь транспорт и обвязка пишется руками. Если то, что приходится писать свой сервлет, для работы через http протокол. Или поднимать ручками сервер для работы на сокетах
То по мне это не большая проблема: написать 40-50 строчек кода для одного сервиса.
Мы mirage и используем. Дело в том, что при таком подходе для изменения API ты должен вносить несвязанные изменения и на стороне клиента и на стороне сервера. В итоге конфигурация для mirage разрослась. Плюс, как я писал некоторые разработчики меняя модель данных на сервере не всегда меняли модель данных на мираже. Т.е. у нас в mirage есть представление списка сущностей. Список из 20 — 30 записей. И добавление одного поля в данный список приносило много боли.
Когда модель состоит из десятка сущностей — это не очень проблемно, когда количество сущностей кратно возрастает, то возрастает и стоимость «ревью».
Если можно убрать момент «ревью»API, то лучше его убрать.
Писать тесты для выявления ошибок API, это опять вопрос синхронизации. Как можно защититься от того, что разработчик напишет тест только для бекенда, а для «фронтенда» забудет?
Сейчас же с выносом API в единое место, у нас есть гарантия на уровне компиляции, что модели для сервера и клиента будут согласованы. Т.е. во время сборки проекта будет подложена последняя версия API. До этого гарантией служили «соглашения».
Изначально на этом проекте тесты написаны над HashMap (эмуляция БД). Т.к. это маленький микросервис, то сложных операций нет: сохранить в таблицу с автоинкрементом, поиск по одному/двум полям. Тесты генерируют малое количество данных, так что такой подход вполне корректен :)
Итак есть отдельный maven модуль, в котором только тесты. Вся бизнес логика в других модулях. Компилирование бизнес-логики в текущих расчётах не учитывается.
В модуле dao объявлено два liqubase changeSet. Добавление таблицы и добавление новых полей в таблицу(эти скрипты естественно не запускаются, если работаю над HashMap).
Есть 5 классов с тестами. Первый класс с пустым тестом, для инициализации SpringContext. В остальных 4х классах 20 тестов. Для каждого варианта делал три запуска тестов. Перед запуском тестов делал mvn clean. Время выполнение брал из логов maven.
HashMap:
— Инициализация: 4.7s
— Тесты: 1.8s
— Maven package: 20.5s
HSQLDB (memory):
— Инициализация: 10.7s
— Тесты: 2.7s
— Maven package: 29.8s
Postgres (in docker):
— Инициализация: 9,9s
— Тесты: 3,1s
— Maven package: 26,9s
EmbendedPostgres замедляет работу. Он создаёт новый инстанс на старт нового SpringContext (с запуском всех скриптов обновления). В той же статье, о которой я упомянул было написано, что ребята научились поднимать один инстанс на всю сессию тестов вне зависимости от того, сколько запуститься Spring Context-ов.
Именно по этому мы постепенно мигрируем на «локальные» БД. Это и единичный запуск скриптов обновления или вообще его отсутствие и возможность глазами посмотреть данные в БД. И возможность проверить, как произойдёт накат изменений на существующую структуру данных.
На сервере сборок поднимается Docker-контейнер с Postgres, который потом удаляется тем самым «очищая» результаты работы тестов.
Если Postgres начнёт тормозить, то всегда можно будет настроить RamDisk.
Но если речь про интеграционные тесты, то тут как раз надо проверять интеграцию :) и моменты с БД скрывают не очевидные подводные камни.
Я выше описал, как мы стараемся решать часть проблем с уровнем БД в интеграционных тестах.
1. В современных движках разработки UI есть свои тесты, включая проверку работы компонентов. Это отдельная тема.
2. Тесты на производительность не запускаются один раз. Т.к. производительность, это не одна операция в единицу секунды. А 10^x операций в течении определённого периода времени.