Я не утверждал что модульные не нужны, просто пирамиду тестирования многие делают не правильно, делая упор на модульные тесты, которые пишутся дольше, чаще требуют внимание. Модульные работают и оправданы там где нет внешнего API или других механизмов для проверки логики или большое количество вариантов (где интеграционный тест будет очень долго работать)
В моем понимании пирамида тестирования примерно такая
40% Модульные 40% Интеграционные 20% UI Тесты + Ручное тестирование для сложных кейсов, дизайна, где написание других видов тестов не рационально
Для примера, сегодня написал два модульных теста, примерно по 100 строк каждый. Проверил позитивный и негативный сценарии. Запустил — вроде всё good. Затем написал интеграционный тест строк на 60 (проверяет туже функцию, только уже через контроллер), и вуаля — именно интеграционный тест отловил багу, поскольку как оказалось перепутал в рабочем коде идентификаторы сущностей.
На текущем проекте интеграционные за минуту всю систему проверяют, тут видимо от прямоты рук все зависит и от контекста проекта. Я не писал что против слоев (горизонтальных), DDD, вертикальных, хотя думаю что все это шляпа, надо что-то новенькое и более красивое )
ИМХО Разделение на слои, микросервисные и любое другое разделение помогает потом когда делаешь фичу как оленю скакать между тонной файлов и проектов и добавлять по одной строке кода и еще тренирует память, чтобы нигде и ничего не забыть )
А ну и локально потом минут 20 все это хозяйство собирать, на медленных обычных ПК до часа и более..
Тесты могут быть интеграционными через API например, я вот модульные не уважаю от слова совсем, только для в определенных кейса[, интеграционные через API отлично все могут проверить и не заставляют что-то менять и выносить, реже ломаются и быстрее пишутся
Все сложные программы просто кишат недоделками и багами. Браузеры — очень сложные продукты, которые реализуют непомерно раздутые стандарты (CSS — около 1000 свойств).
Даже базовые, относительно простые вещи в разных браузерах могут не работать. Например, Firefox не умеет при локальном открытии архива HTML-файлов использовать LocalStorage в пределах папки с документами (прямо со смеху падаю, детский сад...)
Как-то помню, Oracle не умел правильно ANSI-синтаксис JOIN поддерживать, только свой кривой с плюсиками
Спустя 10 лет, опять столкнувшись с Oracle, похудел от ошибок в кешировании — полная дичь.
ИМХЛ Поэтому очень хороший UI на веб не сделать, все одни компрамисы и сегодня работает, завтра ломается после обновления очередного браузера...
Ладно, пойду в своей сложной программе бесконечные баги править )
В некоторых БД буквально сотни зарезервированных слов (еще есть и списки слов которые возможно будут зарезервированы), например в MS-SQL слово user является зарезервированным, поэтому надо писать select u.id from dbo.[user] as u, использование множественного числа для названий таблиц буквально сводит такие неудобства к 0.
Если добавить что для многих приложений со временем встает необходимость поддержки нескольких БД или как сейчас массовый переход с Oracle и MS-SQL, все еще сложнее становиться.
Обычно БД и данные живут дольше чем клиентский софт, django и orm тут очень частная вещь...
Для MS-SQL полностью поддерживаю множественное число для таблиц, чтобы потом не надо было постоянно [] писать, если что ORM эти символы тоже пишут зачастую
Помню писал небольшую утилиту с этой технологией от MS, она диаграммы C4 сначала проверяла, потом добавлял возможность генерации C4, сейчас наверное менее актуальная тема, везде сплошные ИИ технологии все заменяют постепенно.
Если принципы в манифесте не устраивают это просто непонимание или недостаток опыта в разработке или неверная понимание написанного
Принципы общие, они не учитывают контекст продукта и квалификацию команд
Общие принципы трудно написать
Писать, что мол частые поставки вредны - тут просто надо итерационно простыми шагами поставлять, для части продуктов это жизненно необходимо, насколько я помню авторы писали принципы для традиционных корпоративных приложений, там можно поставлять часто.
Я лично мог каждые 15-30 минут поставлять - но я сидел недалеко от пользователей и общался лично
connection.fetch(query, args) -> result - норм тема, особенно если в query вызов хранимки, надо что-то похожее на универсальные хранимки до уровня БД, пока идея ждет своего героя.
Используется, переписывал на одном месте работы методы API с Delphi на C#, в основном благодаря Net.Core код практически уходит, становиться в разы меньше и проще. Хотя методы API на Delphi немного быстрее работали :)
Можно еще по более простым признакам определить, если компания небольшая и частенько вывешивает одинаковые вакансии, скорее всего там текучка (из личного опыта).
Если у вас опыт 18 лет, а с вами связывается тупая HR девочка, компания видимо деревянная, такая работа не подойдет, если вы нацелены на результат или цените свое время, ненавидите бюрократию и т.д.
Если компания не профильная, например строительная, готовьтесь в большинстве случаев стать на уровне охранников и уборщиц. Хотя задачки бывают интересные и больше свободы в техническом плане (меньше документации и неприятной рутины).
Есть некий KPI по разработчикам, тут вообще может быть конская система мотивации, будете с коллегами пахать от звонка до звонка, код как правило плохой (все нацелены только на выполнение своих задач). Под конец месяца аврал, все будут спешить свои задачи сдать.
Просят списывать по 8 частов в день на задачи, уже не реально...
Я не утверждал что модульные не нужны, просто пирамиду тестирования многие делают не правильно, делая упор на модульные тесты, которые пишутся дольше, чаще требуют внимание. Модульные работают и оправданы там где нет внешнего API или других механизмов для проверки логики или большое количество вариантов (где интеграционный тест будет очень долго работать)
В моем понимании пирамида тестирования примерно такая
40% Модульные
40% Интеграционные
20% UI Тесты
+ Ручное тестирование для сложных кейсов, дизайна, где написание других видов тестов не рационально
Для примера, сегодня написал два модульных теста, примерно по 100 строк каждый. Проверил позитивный и негативный сценарии. Запустил — вроде всё good. Затем написал интеграционный тест строк на 60 (проверяет туже функцию, только уже через контроллер), и вуаля — именно интеграционный тест отловил багу, поскольку как оказалось перепутал в рабочем коде идентификаторы сущностей.
На текущем проекте интеграционные за минуту всю систему проверяют, тут видимо от прямоты рук все зависит и от контекста проекта. Я не писал что против слоев (горизонтальных), DDD, вертикальных, хотя думаю что все это шляпа, надо что-то новенькое и более красивое )
ИМХО
Разделение на слои, микросервисные и любое другое разделение помогает потом когда делаешь фичу как оленю скакать между тонной файлов и проектов и добавлять по одной строке кода и еще тренирует память, чтобы нигде и ничего не забыть )
А ну и локально потом минут 20 все это хозяйство собирать, на медленных обычных ПК до часа и более..
Тесты могут быть интеграционными через API например, я вот модульные не уважаю от слова совсем, только для в определенных кейса[, интеграционные через API отлично все могут проверить и не заставляют что-то менять и выносить, реже ломаются и быстрее пишутся
Все сложные программы просто кишат недоделками и багами.
Браузеры — очень сложные продукты, которые реализуют непомерно раздутые стандарты (CSS — около 1000 свойств).
Даже базовые, относительно простые вещи в разных браузерах могут не работать.
Например, Firefox не умеет при локальном открытии архива HTML-файлов использовать LocalStorage в пределах папки с документами (прямо со смеху падаю, детский сад...)
Как-то помню, Oracle не умел правильно ANSI-синтаксис JOIN поддерживать, только свой кривой с плюсиками
Спустя 10 лет, опять столкнувшись с Oracle, похудел от ошибок в кешировании — полная дичь.
ИМХЛ
Поэтому очень хороший UI на веб не сделать, все одни компрамисы и сегодня работает, завтра ломается после обновления очередного браузера...
Ладно, пойду в своей сложной программе бесконечные баги править )
В некоторых БД буквально сотни зарезервированных слов (еще есть и списки слов которые возможно будут зарезервированы), например в MS-SQL слово user является зарезервированным, поэтому надо писать select u.id from dbo.[user] as u, использование множественного числа для названий таблиц буквально сводит такие неудобства к 0.
Если добавить что для многих приложений со временем встает необходимость поддержки нескольких БД или как сейчас массовый переход с Oracle и MS-SQL, все еще сложнее становиться.
Обычно БД и данные живут дольше чем клиентский софт, django и orm тут очень частная вещь...
Для MS-SQL полностью поддерживаю множественное число для таблиц, чтобы потом не надо было постоянно [] писать, если что ORM эти символы тоже пишут зачастую
Мне в целом понравилась статья, на каждый пункт даны объяснения, тоже подобное что-то писал про базы данных https://habr.com/ru/articles/774154/
Соглашусь с большинством пунктов, понятно что бывают исключения, тут хоть как пиши статю все равно накидают )
Все зависит от контекста, автор по некоторым пунктам перегнул конечно, типа создания индексов по условиями фильтрации
Универсального подхода не бывает, многое зависит от контекста, решаемых задачи и под-задач.
Помню писал небольшую утилиту с этой технологией от MS, она диаграммы C4 сначала проверяла, потом добавлял возможность генерации C4, сейчас наверное менее актуальная тема, везде сплошные ИИ технологии все заменяют постепенно.
Ссылка не работает
На C# код тестов тоже можно писать лаконично и компактно
Побуду сексистом, но лучше парней в таком ракурсе в посты не добавлять
Если принципы в манифесте не устраивают это просто непонимание или недостаток опыта в разработке или неверная понимание написанного
Принципы общие, они не учитывают контекст продукта и квалификацию команд
Общие принципы трудно написать
Писать, что мол частые поставки вредны - тут просто надо итерационно простыми шагами поставлять, для части продуктов это жизненно необходимо, насколько я помню авторы писали принципы для традиционных корпоративных приложений, там можно поставлять часто.
Я лично мог каждые 15-30 минут поставлять - но я сидел недалеко от пользователей и общался лично
connection.fetch(query, args) -> result - норм тема, особенно если в query вызов хранимки, надо что-то похожее на универсальные хранимки до уровня БД, пока идея ждет своего героя.Мне лично статья на Хабре помогла относительно просто пройти собеседования, без выноса мозга. Ссылки на свои статьи добавляю в резюме.
Тоже не понял, сначала подумал что-то более крутое, а так похоже на EAV просто ребрендинг
Норм так, добавлю в свою рисовалку схем (так раз на очереди подобные фичи) https://pikabu.ru/story/razrabatyivayu_utilitu_dlya_formirovaniya_skhem_baz_dannyikh_11202567
Используется, переписывал на одном месте работы методы API с Delphi на C#, в основном благодаря Net.Core код практически уходит, становиться в разы меньше и проще. Хотя методы API на Delphi немного быстрее работали :)
Можешь ссылку дать?
Можно еще по более простым признакам определить, если компания небольшая и частенько вывешивает одинаковые вакансии, скорее всего там текучка (из личного опыта).
Если у вас опыт 18 лет, а с вами связывается тупая HR девочка, компания видимо деревянная, такая работа не подойдет, если вы нацелены на результат или цените свое время, ненавидите бюрократию и т.д.
Если компания не профильная, например строительная, готовьтесь в большинстве случаев стать на уровне охранников и уборщиц. Хотя задачки бывают интересные и больше свободы в техническом плане (меньше документации и неприятной рутины).
Есть некий KPI по разработчикам, тут вообще может быть конская система мотивации, будете с коллегами пахать от звонка до звонка, код как правило плохой (все нацелены только на выполнение своих задач). Под конец месяца аврал, все будут спешить свои задачи сдать.
Просят списывать по 8 частов в день на задачи, уже не реально...