"на бумаге" всё логично вот как раз и должны быть люди которые под сомнения поставят эту логичность обычно у которых есть опыт такого, например лиды
Спихивать ответственность на тимлидов - плохая практика. Разработчики так разленятся думать и будут писать говнокод, который должен будет настырно контролировать лид.
конечно лид проглядел значит он виноват, это его команда уронила, а он не проконтролировал, не сказал протестить лучше, больше, и т.д. Ничего настырно контролировать не нужно, если человек не тянет, то возможно или задачи не по уровню отдаются, или наняли не того, всегда есть разные варианты решения
Нет, не было у них похожих кейсов. Там же написано, что все роняли прод по такой то причине (другой).
цитата автора из текста: "Но есть более правильный вариант, к которому мы пришли вместе с разработчиком из соседней команды — она тоже недавно прокололась на таком кейсе."
В целом из текста не понятна роль тим лида в команде, т.е. ситуация с добавлением индекса или колонки в бд не выглядит как что то экстраординарное, но всё же требует повышенного внимания, а здесь получается что никакого контроля от старших коллег по цеху не было, что настораживает, или он просто не разбирается как такое должно быть реализовано, (а это уже проблемы посерьёзнее). Подтверждение тому в словах автора что кто то из коллег уже ронял прод с похожим кеййсом и похоже никого это так и не насторожило.
Если есть вызовы библиотек написанных например на СИ , Го не сможет их в бинарник засунуть все, так что внешние зависимости на libc останутся. Можно musl использовать для сборки тогда оно будет одним бинарником. Но просто переменной окружения не достаточно. (Это всё для линукса я написал)
Для этого можно написать отдельные тесты, плюс я не очень понимаю про какие потоки вы говорите, если это относиться к параллельным запросам к апи для изменения данных то тут нормально может справиться БД если запросы и ограничения на таблицы выставленны верно. В моем примере инстанс бд будет один. Тесты должны быть изолированны друг от друга, мне кажется это одно из основных правил написания тестов.
Хм, автор сказал как он тестирует приложение, вызывая run и накатывает миграции и тому подобное, но как автор после каждого вызова теста который что то добавляет в БД потом её очищает, чтобы не получить side effect от мусора оставшегося после предыдущего теста? Пересоздавать БД каждый раз дорого.
Плюс не очень понятно как работает такой подход если используется авторизация через сторонний сервис который не так то просто замокать. (Например auth0).
Для тестирования HTTP api я обычно применяю похожий подход но исключаю некоторые зависимости вроде миддлвар с проверкой авторизации. Т.е. у меня в server_test.go будет своя функция которая сформирует хендлеры как и в проде, но за исключением каких то зависимостей, плюс данная функция по мимо хендлера вернёт коннект к тестовой бд и прокинуный в сервисы репозиторий для работы с БД.
RepoDB использует тот же коннект что вернётся из функции. Затем в табличной тесте есть функция setup() которая возвращает функцию teardown() в setup я открываю транзакцию и заменяю ей исходный коннект который лежит в RepoDB. Теперь всё что я создам для теста и всё что создаст тест будет откачено в teardown() функции после завершения теста.
Дело не в компенсации а прецеденте, теперь такие же иски в суде будут рассматриваться быстрее так как уже есть похожие случаи, а так же компания подумает получше чем доводить дело до суда, чем больше проигравших дел тем лучше исковая база для новых в будущем.
Как по мне вместо атомарных коммитов лучше создавать атомарные тикеты и саб тикеты чтобы легче было отследить изменения, не знаю как у вас но в нашем проекте если что то пошло не так откатывают всю фичу а не какой то отдельный коммит из замёрдженной ветки, так что смысл хранить все коммиты а не сквошить в один особого нет.
Ну не знаю, я вот думаю если там ничего нет я бы лучше ошибку поймал и уже сам решу ошибка или нет, ведь дальше мне надо будет серрилизовать данные, а если там nil у меня все грохнется без проверки, так если проверять я бы лучше проверил на ошибку чем на то что значение nil.
Наверное если прочитать этот отрывок то станет понятно, что автор имел ввиду под программировать сложно, написать портянку не читаемого и не поддерживаемого кода не значит уметь программировать.
Таким образом у меня выполняется управление файлами журнала (аля logrotate) и уведомление на почту при падениях приложения.
Т.е. у вас в конфигурации есть информация о названии лог файлов и пути до них, как по мне это только усложняет конфиг и создаёт доп места которые могут поломаться или забыться, кроме того поменять название или путь до файлов логов не получиться без рестарта приложения. Я придерживаюсь правила что, приложение должно стримить в стандартный вывод откуда этот поток может забирать управляющий процесс который ваше приложение запускает, типа супервизора или пода если это всё в кубере и перенаправлять в файл или логсташ/кафка/етц. То же самое и про ротацию. Приложению ни к чему знать о ротации логов ведь это не влияет на его работу, а только создаёт доп логику.
Хм какая то "хромая" аналитика какой сферический запрос в вакууме будет быстрее делая заключение есть тело в запрсе или нет. Вообще то http это текстовый протокол и стандартом не запрещено передавать тело запроса при использовании get метода, апи эластика так делает.
Сельдерей такая большая либа, с кучей функционала который в большинстве случаев не нужен совсем, не проще взять нечто не такое большое типа ARQ ? Быстрый, работает с редисом, использует asyncio под капотом, кода минально, но вроде всё основное запусти таску в бекграунде, присутствует.
Во-первых зачем каждый раз создавать инстанс фабирки которая будет возвращать сессии. Это нужно сделать один раз как и с engine переменной.
Во-вторых, создание сессии на время жизни всего запроса к АПИ, может приводить к ошибкам. Например если нужно выполнить асинхронно несколько корутин внутри которых есть обращение к БД и для этого используется один инстанс сессии, полученный из зависимости. Особенной если хочется писать в "style 2.0" стиле готовя запросы через insert()/select()/update().
Тесты обьединяются в тестовый класс (это тестовый сьют для pytest) + как сказано в начале статьи, используется паттерн PageObject
Я вижу что они в классы объединены, я не понял зачем, так как пайтест парадигма как раз в том и заключается что ты пишешь атомарные тесты, там нет наследований как в юнит тестах всё постороенно на функциях и декораторах.
Ваш ответ
Как написано в статье, магия с request это один из вариантов использования, о котором необходимо знать, к примеру для того, чтобы не прокидывать драйвер во все тесты в качестве аргумента
Противоречит следующему
Касательно к примера с тестовыми данными, да, несомненно проще прокидывать фикстуру в качестве аргумента в тест
Не вижу ничего плохого прописывать в каждый тест аргумент функции.
Про аннотации типов согласен, но их даже многие крутые разрабы не используют, а для новичков это лишние сбивающие с толку каракули в коде
Эм что это за крутые разрабы которые в современном питоне не используют типы? Может они и тесты не пишут? А то знаете какие то портянки кода не нужные.... Без типов и их статической проверки, если он сложнее одного файла, ваш код превращается в мишуру, которую приходится разгадывать в рантайме.
Да вроде бы оригинальная документация на оф сайте и так объясняет все что нужно.
Ещё не понял зачем в классы объединять тесты?
Эта магия с созданием атрибутов через request фикстуру выглядит не дружелюбно к чтению. Нужно ещё догадаться откуда оно там пришло, не проще ли передать в нужный тест фикстуру login, как параметр функции? Так бонусом ещё и легко указать тип для значения фикстуры что важно, так как в современном питоне принято использовать аннотации типов.
Эм ну вообще-то это шутка не про двоичную систему а про цифру с которой начинается индекс в массивах. В первом варианте это с нуля, а вот во втором это с единицы.
У нас мы используем для этих целей логгер и эластик. Т.е. как пример прилетел запрос от пользовател,для него создаётся уникальный ID который прокидывается в контекст живущий пока идёт запрос, далее в коде мы просто логгируем события дописывая уникальный ID к каждой строке. Если нужно вызвать какой то ещё сервис уникальный ID прокидывается в запросе в виде заголовка и уже следующий сервис его использует. Позднее через filebeat или vector данные попадают в logstash и затем в эластик где индексируются и визуализируются через kibana. Т.е. зная например уникальный ID попавший в сентри вместе с ошибкой можно проследить весь путь запроса. Ах да и мы используем структурированные json строки для логов
Судя по вашему описанию jaeger выглядит как ещё один логгер только умнее и со своим веб интерфейсом. Это же самое можно сделать и с помощью ELK, просто отправляя и получая из сервиса к сервису уникальный для запроса реквест ид, который указывается при логгировании действий ну и получается отправляется в эластик где потом на его основе можно строить какие угодно графики.... хоть трекать потребление памяти хоть длительность запрса. Но конечно это просто мои рассуждения может он ещё что то может чего я не знаю. Кстати чисто для справки для logstash filebeat есть вполне годная замена vector используем его в проде.
"на бумаге" всё логично вот как раз и должны быть люди которые под сомнения поставят эту логичность обычно у которых есть опыт такого, например лиды
конечно лид проглядел значит он виноват, это его команда уронила, а он не проконтролировал, не сказал протестить лучше, больше, и т.д. Ничего настырно контролировать не нужно, если человек не тянет, то возможно или задачи не по уровню отдаются, или наняли не того, всегда есть разные варианты решения
цитата автора из текста: "Но есть более правильный вариант, к которому мы пришли вместе с разработчиком из соседней команды — она тоже недавно прокололась на таком кейсе."
В целом из текста не понятна роль тим лида в команде, т.е. ситуация с добавлением индекса или колонки в бд не выглядит как что то экстраординарное, но всё же требует повышенного внимания, а здесь получается что никакого контроля от старших коллег по цеху не было, что настораживает, или он просто не разбирается как такое должно быть реализовано, (а это уже проблемы посерьёзнее). Подтверждение тому в словах автора что кто то из коллег уже ронял прод с похожим кеййсом и похоже никого это так и не насторожило.
Если есть вызовы библиотек написанных например на СИ , Го не сможет их в бинарник засунуть все, так что внешние зависимости на libc останутся. Можно musl использовать для сборки тогда оно будет одним бинарником. Но просто переменной окружения не достаточно. (Это всё для линукса я написал)
Для этого можно написать отдельные тесты, плюс я не очень понимаю про какие потоки вы говорите, если это относиться к параллельным запросам к апи для изменения данных то тут нормально может справиться БД если запросы и ограничения на таблицы выставленны верно. В моем примере инстанс бд будет один. Тесты должны быть изолированны друг от друга, мне кажется это одно из основных правил написания тестов.
Хм, автор сказал как он тестирует приложение, вызывая run и накатывает миграции и тому подобное, но как автор после каждого вызова теста который что то добавляет в БД потом её очищает, чтобы не получить side effect от мусора оставшегося после предыдущего теста? Пересоздавать БД каждый раз дорого.
Плюс не очень понятно как работает такой подход если используется авторизация через сторонний сервис который не так то просто замокать. (Например auth0).
Для тестирования HTTP api я обычно применяю похожий подход но исключаю некоторые зависимости вроде миддлвар с проверкой авторизации. Т.е. у меня в server_test.go будет своя функция которая сформирует хендлеры как и в проде, но за исключением каких то зависимостей, плюс данная функция по мимо хендлера вернёт коннект к тестовой бд и прокинуный в сервисы репозиторий для работы с БД.
RepoDB использует тот же коннект что вернётся из функции. Затем в табличной тесте есть функция setup() которая возвращает функцию teardown() в setup я открываю транзакцию и заменяю ей исходный коннект который лежит в RepoDB. Теперь всё что я создам для теста и всё что создаст тест будет откачено в teardown() функции после завершения теста.
Дело не в компенсации а прецеденте, теперь такие же иски в суде будут рассматриваться быстрее так как уже есть похожие случаи, а так же компания подумает получше чем доводить дело до суда, чем больше проигравших дел тем лучше исковая база для новых в будущем.
Как по мне вместо атомарных коммитов лучше создавать атомарные тикеты и саб тикеты чтобы легче было отследить изменения, не знаю как у вас но в нашем проекте если что то пошло не так откатывают всю фичу а не какой то отдельный коммит из замёрдженной ветки, так что смысл хранить все коммиты а не сквошить в один особого нет.
Ну не знаю, я вот думаю если там ничего нет я бы лучше ошибку поймал и уже сам решу ошибка или нет, ведь дальше мне надо будет серрилизовать данные, а если там nil у меня все грохнется без проверки, так если проверять я бы лучше проверил на ошибку чем на то что значение nil.
Все просто, не нравится не скачивайте приложение. А что гугл и эпл перестали следить за пользователями?
Наверное если прочитать этот отрывок то станет понятно, что автор имел ввиду под программировать сложно, написать портянку не читаемого и не поддерживаемого кода не значит уметь программировать.
Т.е. у вас в конфигурации есть информация о названии лог файлов и пути до них, как по мне это только усложняет конфиг и создаёт доп места которые могут поломаться или забыться, кроме того поменять название или путь до файлов логов не получиться без рестарта приложения. Я придерживаюсь правила что, приложение должно стримить в стандартный вывод откуда этот поток может забирать управляющий процесс который ваше приложение запускает, типа супервизора или пода если это всё в кубере и перенаправлять в файл или логсташ/кафка/етц. То же самое и про ротацию. Приложению ни к чему знать о ротации логов ведь это не влияет на его работу, а только создаёт доп логику.
Хм какая то "хромая" аналитика какой сферический запрос в вакууме будет быстрее делая заключение есть тело в запрсе или нет. Вообще то http это текстовый протокол и стандартом не запрещено передавать тело запроса при использовании get метода, апи эластика так делает.
Сельдерей такая большая либа, с кучей функционала который в большинстве случаев не нужен совсем, не проще взять нечто не такое большое типа ARQ ? Быстрый, работает с редисом, использует asyncio под капотом, кода минально, но вроде всё основное запусти таску в бекграунде, присутствует.
async def get_session()Написан не правильно.Во-первых зачем каждый раз создавать инстанс фабирки которая будет возвращать сессии. Это нужно сделать один раз как и с engine переменной.
Во-вторых, создание сессии на время жизни всего запроса к АПИ, может приводить к ошибкам. Например если нужно выполнить асинхронно несколько корутин внутри которых есть обращение к БД и для этого используется один инстанс сессии, полученный из зависимости. Особенной если хочется писать в "style 2.0" стиле готовя запросы через insert()/select()/update().
Так же стоит сказать что asyncpg который Алхимия использует для реализации асинхронных вызовов к БД не работает если БД "спрятана" за балансировщиком типа pgbouncer. Так как asyncpg имеет свой пул подключений от чего может возникать ошибка типа "prepared statement error" - https://magicstack.github.io/asyncpg/current/faq.html#why-am-i-getting-prepared-statement-errors
Я вижу что они в классы объединены, я не понял зачем, так как пайтест парадигма как раз в том и заключается что ты пишешь атомарные тесты, там нет наследований как в юнит тестах всё постороенно на функциях и декораторах.
Ваш ответ
Противоречит следующему
Не вижу ничего плохого прописывать в каждый тест аргумент функции.
Эм что это за крутые разрабы которые в современном питоне не используют типы? Может они и тесты не пишут? А то знаете какие то портянки кода не нужные.... Без типов и их статической проверки, если он сложнее одного файла, ваш код превращается в мишуру, которую приходится разгадывать в рантайме.
Да вроде бы оригинальная документация на оф сайте и так объясняет все что нужно.
Ещё не понял зачем в классы объединять тесты?
Эта магия с созданием атрибутов через request фикстуру выглядит не дружелюбно к чтению. Нужно ещё догадаться откуда оно там пришло, не проще ли передать в нужный тест фикстуру login, как параметр функции? Так бонусом ещё и легко указать тип для значения фикстуры что важно, так как в современном питоне принято использовать аннотации типов.
https://github.com/robpike/filter
Ну вроде как есть такое поделие от Роба Пайка, но как он там заметил можно просто for использовать смысла столько же :)
Эм ну вообще-то это шутка не про двоичную систему а про цифру с которой начинается индекс в массивах. В первом варианте это с нуля, а вот во втором это с единицы.
У нас мы используем для этих целей логгер и эластик. Т.е. как пример прилетел запрос от пользовател,для него создаётся уникальный ID который прокидывается в контекст живущий пока идёт запрос, далее в коде мы просто логгируем события дописывая уникальный ID к каждой строке. Если нужно вызвать какой то ещё сервис уникальный ID прокидывается в запросе в виде заголовка и уже следующий сервис его использует. Позднее через filebeat или vector данные попадают в logstash и затем в эластик где индексируются и визуализируются через kibana. Т.е. зная например уникальный ID попавший в сентри вместе с ошибкой можно проследить весь путь запроса. Ах да и мы используем структурированные json строки для логов
Судя по вашему описанию jaeger выглядит как ещё один логгер только умнее и со своим веб интерфейсом. Это же самое можно сделать и с помощью ELK, просто отправляя и получая из сервиса к сервису уникальный для запроса реквест ид, который указывается при логгировании действий ну и получается отправляется в эластик где потом на его основе можно строить какие угодно графики.... хоть трекать потребление памяти хоть длительность запрса. Но конечно это просто мои рассуждения может он ещё что то может чего я не знаю. Кстати чисто для справки для logstash filebeat есть вполне годная замена vector используем его в проде.