Если бизнес код все ещё понятен и юзабелен, то поддерживать снежный ком и месиво из тупых и бесполезных юнит тестов уже не представляется возможным. Код не эволюционирует, рефакторинг не производится, новые фичи прикручиваются сбоку, либо вообще игнорятся. Проект а станции, зато метрики покрытия зелёные, QA счастлив!
Никто не умеет писать хороший код. Есть те, кто думают, что пишут хороший код потому что им так сказали в книжке или на презентации люди, которые уже 20 лет ничего не писали.
Тут особо не о чем рассказывать. Base -- все ещё достаточно сильная гарантия, которая обеспечивает частичную консистентность в некоем будущем. Большинство систем вообще никак не гарантируют консистентность данных, ни в настоящем, ни в будущем, и обеспечивают ее только в случае happy path при отсутствии race condition. Благодаря крайне низкой вероятности подобных сбоев, а также налаженной пользовательской поддержке, данные системы имеют быть место.
Любые обязательные метрики, без учёта контекста - это бред.
Благо в этом мире бреда хватает на всех.
Написание теста на свой код - это моментальный сигнал о том, хороший ли у тебя код
Да всем ровным счётом по барабану какой там у вас код и как там он устроен. В проекте важны дедлайны и соответствует ли функционал заявленной бизнес спецификации или нет. Именно это и нужно тестировать. При наличии тестового покрытия функционала, его потом можно отрефакторить без лишнего геморроя.
И как я уже сказал выше, юниты отнюдь не являются метрикой качества кода. В дизайне появляется излишняя фрагментарность, на порядки ухудшающая читабельность, нарушается инкапсуляция и области видимости. С зависимостями все ещё хуже: мокать repository -- глупое и неблагодарное занятие.
Аргументы типа "если вы не любите кошек, то вы не умеете их готовить" -- это фактически единственный аргумент адептов свидетелей ТДД. При всем при том есть стоптцот теоретических изысканий, методик и книг о том, как правильно писать чистый и понятный код. Однако нет ни одной удобоваримой теории как правильно писать тесты. Вся "теория" ограничивается сферическим конем в вакууме ввиде конкретного примера калькулятора, и пачкой наивных абстрактных наставнических соображений, зачастую противоречащих друг другу.
Почему в реальном мире это не работает, неплохо пояснил коллега постом ниже. Из своей практики замечу, что при внедрении метрики обязательного покрытия в 80% разработка проекта замедлилась в 3 раза, кодовая база распухла, а читабельность ухудшилась благодаря излишней фрагментарности. Команда напрочь отказывалась производить всякий рефакторинг из-за сопутствующих проблем с тестами. И главное, это практически никак не повлияло на финальные метрики ошибок.
Страшно трогать, когда на при малейшем тривиальнейшем изменении бизнес логики валятся стоптцот абсолютно бесполезных юнит тестов. Или когда логика мокирования становится в десятки раз сложнее самого функционала, и уже сами тесты являются основными источником ошибок.
Согласен со всем сказанным, кроме пункта 4. И здесь виновата сама архитектура спринга, ибо никогда время запуска приложения не считалось критичным. Разработчики подождут -- им за это платят. В итоге вся эта белебердень с юнитами, слайсами, ленивой инициализацией была придумана, чтобы хоть как-то ускорить тесты. Поэтому если разработчики самого спринга рекомендуют вам писать юниты без контекста где это только возможно, значит они где-то крупно прокололись.
Ну да, в типичном приложении на спринге 70% кода выполняет именно сложную осмысленную вычислительную логику, которая описана как отдельный бизнес кейс ))))
В большинстве случаев приложение -- это тупая надстройка над базой данных, мепящая таблицы в API. Поэтому тестировать что-то там по "слоям" не имеет абсолютно никакого смысла. Берём testcontainers, mockmvc и проверяем вашу CRUD-спеку, абсолютно не заботясь как там оно внутри наговнокожено.
Да все эти ваши юниты -- мусор в проекте. Ни один из них не соответствует никакому реальному бизнес кейсу или сценарию. То, что контекст Spring-а поднимается как черепаха -- это проблема самого спринга, а не вашей методологии или организации проекта.
Многие девелоперы считают, что если их система не удовлетворяет ACID, то она по умолчанию BASE. Это роковое заблуждение. BASE -- достаточно сильная гарантия. Реально практически все системы, которые мне встречались, имплементиоруют "страусиный" принцип и zero consistency. И это банковский и телекоммуникационный сектор.
Это все наивно и хорошо только в теории. Вот описываем мы поля как nonnull, а потом в ход вступает десериализатор, который автоматически парсит пользовательский request и вот вам нулы в nonnull полях. То же самое с ORM и прочими технологиями. Требуется более глубокая поддержка nullability всем стеком.
XML -- это группа стандартов с продуманной семантикой, а JSON в оригинале просто был куском JS кода, внезапно ставший индустриальным стандартом ввиду нативной поддержки на фронте. На данный момент мы наблюдаем неудачные стихийные попытки восполнить отсутствующую семантику при помощи JSON path, JSON schema, поделку openapi, etc. Сравнивать эти два формата по принципу "кто круче" по меньшей мере некорректно.
Вчера поставил на своем Mac-е, все завелось. Хочу выразить огромное спасибо, ибо с mc испытывались постоянные проблемы с клавиатурой, редактором и прочими удобствами.
К подобным абстрактным идеям, о том сколько ангелов уместиться на кончике иглы, следует относиться не более чем как к развлекательной беллетристике.
С одной стороны, идеи кажутся простыми и разумными, с другой -- будучи примененными к реальным вещам, сразу провоцируют стопицот нюансов.
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи. Но кто когда признается в собственной некомпетентности? Всегда найдется причина вовне!
Везде, где только возможно, стараюсь не использовать фреймворки. И хотя стандартный RT джавы уже содержит немало всего, вместе с тем ч не против библиотек, которые содержат максимально необходимый функционал без прочего мусора. Например, для API неплохо подходит Javalin. Template engines вне фреймворка огромное количество (очень прикольный j2html). Для металлизации JSON есть Gson. Для доступа к базе JDBI.
Насчёт DI: в большинстве небольших проектов он вообще лишний, ибо связать 5 бинов можно и вручную. Просто на каждый бин в ApplicationContext заводим соответствующий порождающий метод и все. Там же где он нужен, я использую Guice.
Вообще да, сегодня вырос целый пласт специалистов, которые без фреймворка не осилят написание даже просто проекта, будь то бэк или фронт. У меня в команде чел две недели ковырялся с простой консольной утилитой, в итоге сказал, что ему нужен Spring, и только после этого смог закрыть таску.
TS неплохо лег для всех. Идея -- просто добавить типов к JS. Kotlin всё-таки сильно завязан на Java и JVM. Лучше было бы сразу взять направление на кросс-платформенность.
Если углубиться в тему и отбросить ваниль, то получится сказ о том как "просрать все полимеры". Неплохая и перспективная технология благодаря бездарной политике была сначала выпилена из винды, затем снесена с десктопа, смыта с клиентского веба, практически были просраны все мобильные платформы (только Гугл на свою задницу взял джаву и сильно пожалел потом). На сервере благодаря энтерпрайзному булшиту, веб разработка практически была утрачена в угоду легковесным решениями типа ruby on rails. Все эти JSR спецификации были дорогим и факультативным процессом, и реально никому особо и не впились. Фактически все это время один Spring тащил на себе всю джаву, новый клал по большей части на весь JEE. Около 7 лет застоя языка вызвали отток девелоперов из экосистемы и создание стопицот альтернативных мертворожденных JVM языков. Сегодня джава зацепилась за клауд, но и здесь не все гладко: внезапно оказалось, что она долго стартует, что сильно мешает технологиям с динамическими инстансами, а также не позволяет быть лекговесным языком для написания утилит и скриптов, как Пайтон или JS. ML и AI опять же...
Вообщем, история джавы -- это нифига не история успеха. Скорей вопреки стараниям менеджеров, над все ещё ее использует.
Как жертва бездумного и немотивированного использования различных методологий, я хочу заявить с целью самоутверждения и демонстрации согласия с автором коммента, что скрамы, эджайлы, фреймворки и прочее г. -- это все по то, как на основе посредственной ресурсной базы получить хоть какой-то рабочий результат.
Вот пусть и пишут, им никто не запрещал. Пусть хоть на голове ходят, если это внезапно станет модно. Лично я сначала делаю анализ, дизайн, набрасываю скелет решения, а уж потом итеративно реализовываю его параллельно с тестами.
Вообще TDD -- это методология о том, как написать калькулятор. В реальной среде там возникает куча проблем, о которых постоянно спорят на форумах, такие как: излишняя фрагментация, множественное покрытие, идеализированное окружение, сконцентрированность на внутреннем дизайне вместо бизнес кейсов, общая сложность написания, etc.
Могу ли я сказать, что следую TDD
С другой стороны, почему вас так задевает, являетесь ли вы труЪ адептом TDD или нет? Хотите поговорить об этом? :)
Помню себя 15-20 лет назад, когда всеми силами пытался разобраться как "правильно" писать и огранизовывать код, всасывая всевозможные паттерны и концепты. На определенном этапе я понял, что объективно никакого "правильного" варианта не существует, а большинство идей и концептов -- это не более чем расхайпленное персональное мнение одного или нескольких уважаемых людей, которые последний раз бизнес код писали N-дцать лет назад. А не говорю, что не стоит знать и понимать эти идеи, я лишь призываю скептически к ним относится, в особенности когда они преподносятся как лекарство от всех болезней и диких зверей.
получать возможность тестировать логику с инфраструктурными компонентами, используя такие инструменты, как Testcontainers.
Именно. Все мокированные юниты -- это мусор, который мешает дальнейшей разработке и рефакторингу, и основной смысл которых -- это поднять метрику покрытия. Сегодня мы в основном пишем микросервисы, в которых API -- это фактическая бизнес-спецификация, которая должна быть покрыта тестами и выдерживать регрессии. И фрагментировать тестовое покрытие на более мелкие внутренние компоненты в большинстве случаев не имеет смысла.
Если бизнес код все ещё понятен и юзабелен, то поддерживать снежный ком и месиво из тупых и бесполезных юнит тестов уже не представляется возможным. Код не эволюционирует, рефакторинг не производится, новые фичи прикручиваются сбоку, либо вообще игнорятся. Проект а станции, зато метрики покрытия зелёные, QA счастлив!
Никто не умеет писать хороший код. Есть те, кто думают, что пишут хороший код потому что им так сказали в книжке или на презентации люди, которые уже 20 лет ничего не писали.
Тут особо не о чем рассказывать. Base -- все ещё достаточно сильная гарантия, которая обеспечивает частичную консистентность в некоем будущем. Большинство систем вообще никак не гарантируют консистентность данных, ни в настоящем, ни в будущем, и обеспечивают ее только в случае happy path при отсутствии race condition. Благодаря крайне низкой вероятности подобных сбоев, а также налаженной пользовательской поддержке, данные системы имеют быть место.
Благо в этом мире бреда хватает на всех.
Да всем ровным счётом по барабану какой там у вас код и как там он устроен. В проекте важны дедлайны и соответствует ли функционал заявленной бизнес спецификации или нет. Именно это и нужно тестировать. При наличии тестового покрытия функционала, его потом можно отрефакторить без лишнего геморроя.
И как я уже сказал выше, юниты отнюдь не являются метрикой качества кода. В дизайне появляется излишняя фрагментарность, на порядки ухудшающая читабельность, нарушается инкапсуляция и области видимости. С зависимостями все ещё хуже: мокать repository -- глупое и неблагодарное занятие.
Аргументы типа "если вы не любите кошек, то вы не умеете их готовить" -- это фактически единственный аргумент адептов свидетелей ТДД. При всем при том есть стоптцот теоретических изысканий, методик и книг о том, как правильно писать чистый и понятный код. Однако нет ни одной удобоваримой теории как правильно писать тесты. Вся "теория" ограничивается сферическим конем в вакууме ввиде конкретного примера калькулятора, и пачкой наивных абстрактных наставнических соображений, зачастую противоречащих друг другу.
Почему в реальном мире это не работает, неплохо пояснил коллега постом ниже. Из своей практики замечу, что при внедрении метрики обязательного покрытия в 80% разработка проекта замедлилась в 3 раза, кодовая база распухла, а читабельность ухудшилась благодаря излишней фрагментарности. Команда напрочь отказывалась производить всякий рефакторинг из-за сопутствующих проблем с тестами. И главное, это практически никак не повлияло на финальные метрики ошибок.
Страшно трогать, когда на при малейшем тривиальнейшем изменении бизнес логики валятся стоптцот абсолютно бесполезных юнит тестов. Или когда логика мокирования становится в десятки раз сложнее самого функционала, и уже сами тесты являются основными источником ошибок.
Согласен со всем сказанным, кроме пункта 4. И здесь виновата сама архитектура спринга, ибо никогда время запуска приложения не считалось критичным. Разработчики подождут -- им за это платят. В итоге вся эта белебердень с юнитами, слайсами, ленивой инициализацией была придумана, чтобы хоть как-то ускорить тесты. Поэтому если разработчики самого спринга рекомендуют вам писать юниты без контекста где это только возможно, значит они где-то крупно прокололись.
Ну да, в типичном приложении на спринге 70% кода выполняет именно сложную осмысленную вычислительную логику, которая описана как отдельный бизнес кейс ))))
В большинстве случаев приложение -- это тупая надстройка над базой данных, мепящая таблицы в API. Поэтому тестировать что-то там по "слоям" не имеет абсолютно никакого смысла. Берём testcontainers, mockmvc и проверяем вашу CRUD-спеку, абсолютно не заботясь как там оно внутри наговнокожено.
Да все эти ваши юниты -- мусор в проекте. Ни один из них не соответствует никакому реальному бизнес кейсу или сценарию. То, что контекст Spring-а поднимается как черепаха -- это проблема самого спринга, а не вашей методологии или организации проекта.
Многие девелоперы считают, что если их система не удовлетворяет ACID, то она по умолчанию BASE. Это роковое заблуждение. BASE -- достаточно сильная гарантия. Реально практически все системы, которые мне встречались, имплементиоруют "страусиный" принцип и zero consistency. И это банковский и телекоммуникационный сектор.
Это все наивно и хорошо только в теории. Вот описываем мы поля как nonnull, а потом в ход вступает десериализатор, который автоматически парсит пользовательский request и вот вам нулы в nonnull полях. То же самое с ORM и прочими технологиями. Требуется более глубокая поддержка nullability всем стеком.
XML -- это группа стандартов с продуманной семантикой, а JSON в оригинале просто был куском JS кода, внезапно ставший индустриальным стандартом ввиду нативной поддержки на фронте. На данный момент мы наблюдаем неудачные стихийные попытки восполнить отсутствующую семантику при помощи JSON path, JSON schema, поделку openapi, etc. Сравнивать эти два формата по принципу "кто круче" по меньшей мере некорректно.
Вчера поставил на своем Mac-е, все завелось. Хочу выразить огромное спасибо, ибо с mc испытывались постоянные проблемы с клавиатурой, редактором и прочими удобствами.
К подобным абстрактным идеям, о том сколько ангелов уместиться на кончике иглы, следует относиться не более чем как к развлекательной беллетристике.
С одной стороны, идеи кажутся простыми и разумными, с другой -- будучи примененными к реальным вещам, сразу провоцируют стопицот нюансов.
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи. Но кто когда признается в собственной некомпетентности? Всегда найдется причина вовне!
Везде, где только возможно, стараюсь не использовать фреймворки. И хотя стандартный RT джавы уже содержит немало всего, вместе с тем ч не против библиотек, которые содержат максимально необходимый функционал без прочего мусора. Например, для API неплохо подходит Javalin. Template engines вне фреймворка огромное количество (очень прикольный j2html). Для металлизации JSON есть Gson. Для доступа к базе JDBI.
Насчёт DI: в большинстве небольших проектов он вообще лишний, ибо связать 5 бинов можно и вручную. Просто на каждый бин в ApplicationContext заводим соответствующий порождающий метод и все. Там же где он нужен, я использую Guice.
Вообще да, сегодня вырос целый пласт специалистов, которые без фреймворка не осилят написание даже просто проекта, будь то бэк или фронт. У меня в команде чел две недели ковырялся с простой консольной утилитой, в итоге сказал, что ему нужен Spring, и только после этого смог закрыть таску.
TS неплохо лег для всех. Идея -- просто добавить типов к JS. Kotlin всё-таки сильно завязан на Java и JVM. Лучше было бы сразу взять направление на кросс-платформенность.
Если углубиться в тему и отбросить ваниль, то получится сказ о том как "просрать все полимеры". Неплохая и перспективная технология благодаря бездарной политике была сначала выпилена из винды, затем снесена с десктопа, смыта с клиентского веба, практически были просраны все мобильные платформы (только Гугл на свою задницу взял джаву и сильно пожалел потом). На сервере благодаря энтерпрайзному булшиту, веб разработка практически была утрачена в угоду легковесным решениями типа ruby on rails. Все эти JSR спецификации были дорогим и факультативным процессом, и реально никому особо и не впились. Фактически все это время один Spring тащил на себе всю джаву, новый клал по большей части на весь JEE. Около 7 лет застоя языка вызвали отток девелоперов из экосистемы и создание стопицот альтернативных мертворожденных JVM языков. Сегодня джава зацепилась за клауд, но и здесь не все гладко: внезапно оказалось, что она долго стартует, что сильно мешает технологиям с динамическими инстансами, а также не позволяет быть лекговесным языком для написания утилит и скриптов, как Пайтон или JS. ML и AI опять же...
Вообщем, история джавы -- это нифига не история успеха. Скорей вопреки стараниям менеджеров, над все ещё ее использует.
Как жертва бездумного и немотивированного использования различных методологий, я хочу заявить с целью самоутверждения и демонстрации согласия с автором коммента, что скрамы, эджайлы, фреймворки и прочее г. -- это все по то, как на основе посредственной ресурсной базы получить хоть какой-то рабочий результат.
Вот пусть и пишут, им никто не запрещал. Пусть хоть на голове ходят, если это внезапно станет модно. Лично я сначала делаю анализ, дизайн, набрасываю скелет решения, а уж потом итеративно реализовываю его параллельно с тестами.
Вообще TDD -- это методология о том, как написать калькулятор. В реальной среде там возникает куча проблем, о которых постоянно спорят на форумах, такие как: излишняя фрагментация, множественное покрытие, идеализированное окружение, сконцентрированность на внутреннем дизайне вместо бизнес кейсов, общая сложность написания, etc.
С другой стороны, почему вас так задевает, являетесь ли вы труЪ адептом TDD или нет? Хотите поговорить об этом? :)
Помню себя 15-20 лет назад, когда всеми силами пытался разобраться как "правильно" писать и огранизовывать код, всасывая всевозможные паттерны и концепты. На определенном этапе я понял, что объективно никакого "правильного" варианта не существует, а большинство идей и концептов -- это не более чем расхайпленное персональное мнение одного или нескольких уважаемых людей, которые последний раз бизнес код писали N-дцать лет назад. А не говорю, что не стоит знать и понимать эти идеи, я лишь призываю скептически к ним относится, в особенности когда они преподносятся как лекарство от всех болезней и диких зверей.
Именно. Все мокированные юниты -- это мусор, который мешает дальнейшей разработке и рефакторингу, и основной смысл которых -- это поднять метрику покрытия. Сегодня мы в основном пишем микросервисы, в которых API -- это фактическая бизнес-спецификация, которая должна быть покрыта тестами и выдерживать регрессии. И фрагментировать тестовое покрытие на более мелкие внутренние компоненты в большинстве случаев не имеет смысла.
Сегодня как раз внезапно PR вьюха отключилась. Потратил час, прежде чем нашел тред в саппорте. Обновился, перелогинился и все завелось.
Пожелание на будущее: в подобных ситуациях хочется, чтобы IDE предупреждала о необходимости обновляться например попапом, а не просто отваливаться.
P.S. imho зря на Intellij гонят -- отличные IDE и развиваются в правильном направлении.
Не понимаю зачем склейка с or, когда postgres поддерживает туплы: