На самом деле не только для упрощения моков, просто в статье на это упор, как на проблему актуальную для всех. Другие плюшки это:
- общий подход к написанию кода между разными проектами. Это очень актуально когда разработчиков и проектов много, все привыкли писать по разному и вот этот подход часть стайлгайда в компании. Получаем единый подход у всех.
- проще работать со сложными процессами. Часто у нас нет технически сложного кода, но есть много сложных и длинных процессов. Такой подход позволяет используя композицию, разделять большие процессы на маленькие. Да, можно и без него, но я попробовал и оказалось что там сильно удобней
И за такой базар могу ответить: переведи они тесты на DjangoTestCase, Django.SimpleTestCase - нытья про долгий старт быть не должно, как про суммарную скорость выполнения тестов.
Ну с одной стороны так, с другой нет. Если брать только скорость, то да, вполне вероятно отказ от pytest пошел бы на пользу, а еще можно было бы использовать setUpClass вместе с setUp было бы вообще быстро. Только в реальности это приводит к тому что появляются тесты которые не проходят с первого раза, это и была одна из проблем. Аргументом обычно тут служит что то в роде: "пишите хорошо, не пишите плохо, хороший разрабочик должен уметь" и мне этот аргумент нравится, но он хорошо работает в маленьких проектах. Когда распространить на всю компанию, где есть и очень опытные разработчики и новички, где есть как внутренние сотрудники, так и внешние подрядчики, становится очень сложно поддерживать любые решения которые требуют большей экспертизы.
В итоге получается что для нас это работает не потому что это самый правильный способ писать тесты, а потому что этот способ позволяет упрощать тесты и упрощать проверки, что дает плюс в рамках большой компании.
По использованию django в статье все выглядит, что пользуются в основном drf, мучаются, но продолжают грызть юзать, опять же, без особого понимания: Там кое-где фильтры прям в коде проскакивали, аж больно смотреть.
И вот тоже интересный момент. С одной стороны да, клево когда встречаешь код, где все проверки доступа в permisssion_classes, а вся фильтрация в filter_backends или filterset_class, но для меня всегда была главной сложностью подгонка задачи под эти либы и подходы. Я не спроста написал именно подгонка задачи, потому что сложность появляется не там где мы просто получаем список, а когда к этому добавляются какие то не стандартные фильтры, или проверки. Чем больше задача отходит от простых CRUD операций тем сложней использовать любые generic подходы, проще фильтрацию в filter_queryset засунуть. С другой стороны это все отлично работает на простых CRUD операциях, там мы от этого не уходим и стараемся делать по канонам.
Тут основная идея в том что часто бывает что поток после выполнения каких то действий в сервисах, потом что то еще доделывают во views.py до возвращения ответа. Такое часто бывает если вынесли только сложную часть логики за пределы view. Собственно danilovmy правильно написал.
Спасибо за статью, читается круто. Пример с asyncio.Lock по идее ставит все обращения в очередь, тогда получается что мы не только обновляем данные в кеше последовательно, но и читаем, теряется фактически смысл кеша, так как кэш будет блокирующей частью
На самом деле не только для упрощения моков, просто в статье на это упор, как на проблему актуальную для всех. Другие плюшки это:
- общий подход к написанию кода между разными проектами. Это очень актуально когда разработчиков и проектов много, все привыкли писать по разному и вот этот подход часть стайлгайда в компании. Получаем единый подход у всех.
- проще работать со сложными процессами. Часто у нас нет технически сложного кода, но есть много сложных и длинных процессов. Такой подход позволяет используя композицию, разделять большие процессы на маленькие. Да, можно и без него, но я попробовал и оказалось что там сильно удобней
Спасибо, интересный комментарий)
Ну с одной стороны так, с другой нет. Если брать только скорость, то да, вполне вероятно отказ от pytest пошел бы на пользу, а еще можно было бы использовать setUpClass вместе с setUp было бы вообще быстро. Только в реальности это приводит к тому что появляются тесты которые не проходят с первого раза, это и была одна из проблем. Аргументом обычно тут служит что то в роде: "пишите хорошо, не пишите плохо, хороший разрабочик должен уметь" и мне этот аргумент нравится, но он хорошо работает в маленьких проектах. Когда распространить на всю компанию, где есть и очень опытные разработчики и новички, где есть как внутренние сотрудники, так и внешние подрядчики, становится очень сложно поддерживать любые решения которые требуют большей экспертизы.
В итоге получается что для нас это работает не потому что это самый правильный способ писать тесты, а потому что этот способ позволяет упрощать тесты и упрощать проверки, что дает плюс в рамках большой компании.
И вот тоже интересный момент. С одной стороны да, клево когда встречаешь код, где все проверки доступа в permisssion_classes, а вся фильтрация в filter_backends или filterset_class, но для меня всегда была главной сложностью подгонка задачи под эти либы и подходы. Я не спроста написал именно подгонка задачи, потому что сложность появляется не там где мы просто получаем список, а когда к этому добавляются какие то не стандартные фильтры, или проверки. Чем больше задача отходит от простых CRUD операций тем сложней использовать любые generic подходы, проще фильтрацию в filter_queryset засунуть. С другой стороны это все отлично работает на простых CRUD операциях, там мы от этого не уходим и стараемся делать по канонам.
Тут основная идея в том что часто бывает что поток после выполнения каких то действий в сервисах, потом что то еще доделывают во views.py до возвращения ответа. Такое часто бывает если вынесли только сложную часть логики за пределы view. Собственно danilovmy правильно написал.
Спасибо за статью, читается круто.
Пример с asyncio.Lock по идее ставит все обращения в очередь, тогда получается что мы не только обновляем данные в кеше последовательно, но и читаем, теряется фактически смысл кеша, так как кэш будет блокирующей частью