Да вроде бы оригинальная документация на оф сайте и так объясняет все что нужно.
Ещё не понял зачем в классы объединять тесты?
Эта магия с созданием атрибутов через request фикстуру выглядит не дружелюбно к чтению. Нужно ещё догадаться откуда оно там пришло, не проще ли передать в нужный тест фикстуру login, как параметр функции? Так бонусом ещё и легко указать тип для значения фикстуры что важно, так как в современном питоне принято использовать аннотации типов.
Эм ну вообще-то это шутка не про двоичную систему а про цифру с которой начинается индекс в массивах. В первом варианте это с нуля, а вот во втором это с единицы.
У нас мы используем для этих целей логгер и эластик. Т.е. как пример прилетел запрос от пользовател,для него создаётся уникальный ID который прокидывается в контекст живущий пока идёт запрос, далее в коде мы просто логгируем события дописывая уникальный ID к каждой строке. Если нужно вызвать какой то ещё сервис уникальный ID прокидывается в запросе в виде заголовка и уже следующий сервис его использует. Позднее через filebeat или vector данные попадают в logstash и затем в эластик где индексируются и визуализируются через kibana. Т.е. зная например уникальный ID попавший в сентри вместе с ошибкой можно проследить весь путь запроса. Ах да и мы используем структурированные json строки для логов
Судя по вашему описанию jaeger выглядит как ещё один логгер только умнее и со своим веб интерфейсом. Это же самое можно сделать и с помощью ELK, просто отправляя и получая из сервиса к сервису уникальный для запроса реквест ид, который указывается при логгировании действий ну и получается отправляется в эластик где потом на его основе можно строить какие угодно графики.... хоть трекать потребление памяти хоть длительность запрса. Но конечно это просто мои рассуждения может он ещё что то может чего я не знаю. Кстати чисто для справки для logstash filebeat есть вполне годная замена vector используем его в проде.
Про "нет интерфейсов" это конечно сильное заявление. Я уж молчу про Протоколы и Дженерики. Но чем "__iter__" , "__len__" , "__str__", etc, не интерфейсы? Реализация любых из этих интерфейсов даёт возможности использовать стандартные конструкции и builtin функции для взаимодействия с объектами, будь то итерция или доступ к значениям через словарные скобки, сравнение, и т.д.
Автору явно надо углубить свои знания по питону прежде чем писать такое.
Ничего не нашли наверное потому, что это какое то извращение, уж простите за откровение. Незнаю что значит "тяжёлые" данные, но могу предположить что это их размер и если так то вы наверное вкурсе что в кафку сообщения больше одного метра складывать нельзя, так как она начинает жутко тормозить.
Ну наверное отправляется запрос на который создаётся тикет к которой привязывается какая нить бекграунд задача, уникальный номер тикета возвращается клиенту моментально, и клиент в свою очередь ждёт пока бекграунд таска выполняться и сможет вернуть результат. Клиент по уникальному ид тикета на запрос /poll эндпоинта как раз это и проверяет, готов результат или нет.
Эм я может что то путаю, но открытие файла так же как и его чтение в питоне не является асинхронной операцией, т.е. все эти корутины будут выполнены последовательно а не конкурентно. Может стоило ради примера использовать код (и библиотеки типа aiohttp или httpx) который бы скачивал какие то данные по сети?
Поработав с питоном, для себя, пришёл к выводу, что писать тесты на стандартной библиотеке крайне не удобно. Как пример если функция имеет ветвления, сразу получается что надо написать N тестов с одинаковым вызовом функции и разными входными и (возможно) выходными данными. Код тестов превращается в злостную копипасту. Другое дело pytest с его параметризованными тестами и фикстурами. Получается что нужно написать один тест и скармливать ему разные данные, что очень удобно и просто поддерживать.
Ещё одно это сам стиль тестов при работе с unittest либой, обязательное наследование и как следствие все тесты объединены в классы. Pytest же не накладывает таких ограничений и всегда можно писать тесты без указания классов просто объеденяя их в модули и легко перенося в случае рефакторинга.
ага слышал про subTest, не довелось использовать так как при запуске через pytest тестов написанных с помощью unittest (да так можно) есть ограничение по запуску тестов в несколько потоков. Но думаю в основном рабочая алтернатива параметризации в pytest.
Спасибо за статью. Не знаю насколько возбраняются циклы в тестах, но некоторые неудобства они могут принести если к примеру первый и последний элементы ошибочны то проверить все за раз не получится, придётся сначала исправлять первый кейс, прогонять по новой, увидеть что ещё один кейс сломан и исправлять код для него и т.д. Мне кажется юниттест библиотека питона не сильно гибкая в настройке, как pytest. Стиль тестов в pytest позволяет использовать параметризованные тесты и фикстуры, а так же не размазывать tearDown в отдельной функции а хранить всё рядом с объектом к которому он относится используя генератор для фикстур. Плюс сам тест выглядит как просто функция, не зависящая от классов. Один раз попробовав pytest обратно уже не смог вернуться к стандартной библиотеке. ?
Дисковое пространство для почты даже в 500 мегабайт не такая уж проблема. Переписки вряд ли должны хранится в почте всё время, важные и старые можно убирать в архив, сохранять вложения на диск а сами письма удалять(может сохранив версию письма рядом с вложением если нужно)
Да вроде бы оригинальная документация на оф сайте и так объясняет все что нужно.
Ещё не понял зачем в классы объединять тесты?
Эта магия с созданием атрибутов через request фикстуру выглядит не дружелюбно к чтению. Нужно ещё догадаться откуда оно там пришло, не проще ли передать в нужный тест фикстуру login, как параметр функции? Так бонусом ещё и легко указать тип для значения фикстуры что важно, так как в современном питоне принято использовать аннотации типов.
https://github.com/robpike/filter
Ну вроде как есть такое поделие от Роба Пайка, но как он там заметил можно просто for использовать смысла столько же :)
Эм ну вообще-то это шутка не про двоичную систему а про цифру с которой начинается индекс в массивах. В первом варианте это с нуля, а вот во втором это с единицы.
У нас мы используем для этих целей логгер и эластик. Т.е. как пример прилетел запрос от пользовател,для него создаётся уникальный ID который прокидывается в контекст живущий пока идёт запрос, далее в коде мы просто логгируем события дописывая уникальный ID к каждой строке. Если нужно вызвать какой то ещё сервис уникальный ID прокидывается в запросе в виде заголовка и уже следующий сервис его использует. Позднее через filebeat или vector данные попадают в logstash и затем в эластик где индексируются и визуализируются через kibana. Т.е. зная например уникальный ID попавший в сентри вместе с ошибкой можно проследить весь путь запроса. Ах да и мы используем структурированные json строки для логов
Судя по вашему описанию jaeger выглядит как ещё один логгер только умнее и со своим веб интерфейсом. Это же самое можно сделать и с помощью ELK, просто отправляя и получая из сервиса к сервису уникальный для запроса реквест ид, который указывается при логгировании действий ну и получается отправляется в эластик где потом на его основе можно строить какие угодно графики.... хоть трекать потребление памяти хоть длительность запрса. Но конечно это просто мои рассуждения может он ещё что то может чего я не знаю. Кстати чисто для справки для logstash filebeat есть вполне годная замена vector используем его в проде.
Про "нет интерфейсов" это конечно сильное заявление. Я уж молчу про Протоколы и Дженерики. Но чем "__iter__" , "__len__" , "__str__", etc, не интерфейсы? Реализация любых из этих интерфейсов даёт возможности использовать стандартные конструкции и builtin функции для взаимодействия с объектами, будь то итерция или доступ к значениям через словарные скобки, сравнение, и т.д.
Автору явно надо углубить свои знания по питону прежде чем писать такое.
Ничего не нашли наверное потому, что это какое то извращение, уж простите за откровение. Незнаю что значит "тяжёлые" данные, но могу предположить что это их размер и если так то вы наверное вкурсе что в кафку сообщения больше одного метра складывать нельзя, так как она начинает жутко тормозить.
Ну наверное отправляется запрос на который создаётся тикет к которой привязывается какая нить бекграунд задача, уникальный номер тикета возвращается клиенту моментально, и клиент в свою очередь ждёт пока бекграунд таска выполняться и сможет вернуть результат. Клиент по уникальному ид тикета на запрос /poll эндпоинта как раз это и проверяет, готов результат или нет.
Эм я может что то путаю, но открытие файла так же как и его чтение в питоне не является асинхронной операцией, т.е. все эти корутины будут выполнены последовательно а не конкурентно. Может стоило ради примера использовать код (и библиотеки типа aiohttp или httpx) который бы скачивал какие то данные по сети?
Поработав с питоном, для себя, пришёл к выводу, что писать тесты на стандартной библиотеке крайне не удобно. Как пример если функция имеет ветвления, сразу получается что надо написать N тестов с одинаковым вызовом функции и разными входными и (возможно) выходными данными. Код тестов превращается в злостную копипасту. Другое дело pytest с его параметризованными тестами и фикстурами. Получается что нужно написать один тест и скармливать ему разные данные, что очень удобно и просто поддерживать.
Ещё одно это сам стиль тестов при работе с unittest либой, обязательное наследование и как следствие все тесты объединены в классы. Pytest же не накладывает таких ограничений и всегда можно писать тесты без указания классов просто объеденяя их в модули и легко перенося в случае рефакторинга.
Он там вроде от слияния получит лямов 200+
охотно верим
ага слышал про subTest, не довелось использовать так как при запуске через pytest тестов написанных с помощью unittest (да так можно) есть ограничение по запуску тестов в несколько потоков. Но думаю в основном рабочая алтернатива параметризации в pytest.
Спасибо за статью. Не знаю насколько возбраняются циклы в тестах, но некоторые неудобства они могут принести если к примеру первый и последний элементы ошибочны то проверить все за раз не получится, придётся сначала исправлять первый кейс, прогонять по новой, увидеть что ещё один кейс сломан и исправлять код для него и т.д. Мне кажется юниттест библиотека питона не сильно гибкая в настройке, как pytest. Стиль тестов в pytest позволяет использовать параметризованные тесты и фикстуры, а так же не размазывать tearDown в отдельной функции а хранить всё рядом с объектом к которому он относится используя генератор для фикстур. Плюс сам тест выглядит как просто функция, не зависящая от классов. Один раз попробовав pytest обратно уже не смог вернуться к стандартной библиотеке. ?
Дисковое пространство для почты даже в 500 мегабайт не такая уж проблема. Переписки вряд ли должны хранится в почте всё время, важные и старые можно убирать в архив, сохранять вложения на диск а сами письма удалять(может сохранив версию письма рядом с вложением если нужно)