на 10 попыток внедрения автоматизированных интеграционных - в вашем смысле - тестов удачных - 3, насколько я знаю

я видел автоматизированные интеграционные один раз, и они покрывали только позитивные сценарии - иначе там привет как сложно

но ситуация, когда тесты api прошли, а интеграционные не проходят - она настолько редкая, что об эом обычно не думают

Спасибо

Дало мне пищу для размышлений

Фаулера тут дурачком сумасшедшим объявили, так что плохой пример 🙂 И всю их банду туда же...

😄😄😄

В процедурном стиле синглетон реализуется функциями, изолирующими голб стейт. Но го не только процедурный, он такой же ооп-шный как джава, только без наследования

ну, меня спросили - я ответил) кто не хочет читать Фаулера и его банду - может сходить к первоисточнику, он в статье упоминается

по-моему, только один человек и объявлял

Ну так я и учусь у лучших. Обобщать к примеру 🙂 Да ладно вам, понятное дело я пошутил.

Есть смысл делать указатель map[string]*somestruct  или просто делать map[string]somestruct?

Как это влияет на память и скорость?

надо мерять

по идее мапа всегда передается как поинтер

Не то, чтобы я объявлял кого-то дурачком, но вот смотрю я на эту пирамиду и вижу, что юнит тесты - максимально быстрые, а сервисные и ui - дольше.
Был у меня проект с одним эндпоинтом всего, но покрытый юнитами до состояния близкого к 100%.
Так вот поправить или добавить там функционал с сохранением юнит тестов занимало неделю, хотя интеграционный тест делался автоматически за минуту, и легко поддавался изменениям.
Мне кажется, в разработке много индивидуальщины и как положительные, так и отрицательные отзывы о подходе или инструменте - 2 стороны одной и той же проблемы - отсутствия гибкости

думаю - интеграционные были примерно того же качества, что и юниты

Мне сложно судить, я не тестер.
Юниты при таком покрытии улавливали малейшее изменение внутренней логики и требовали доработок на любой чих.
Интеграционые ближе к здравому смыслу. О каком-то недостестировании речи не шло, шла речь о времени затрат на простейшие доработки.

а я вот думаю - именно о недотестировании и шла речь, просто у вас не было способа об этом узнать

Юниттесты должны тестировать поведение программного интерфейса. Если у вас его поведение на каждый чих меняется непредсказуемо, то у вас с кодом большие проблемы

по моему опыту - если писать unit-тесты сразу, то они примерно удваивают время разработки
если забивать, и пытаться покрывать потом - утраивают

удвоение времени разработки совершенно точно - по моему опыту - отбиваеся на отладке

то есть - выходит то на то, на круг. ну, если писать сразу.

но я вот не люблю отладку, она нервная какая-то все время, потому, что современный софт тестируют всегда прямо в проде.

поэтому мне выгоднее тесты писать

Это не у меня, мне проект достался в таком виде.
Да, в тех юнитах был замокан логгер и его вызовы тестировались. Те новый вызов логгера заставлял переконфигурировать мок