Комментарии 8
Маленькая ошибочка:
views.py — подготавливаем входные парметры для какой то функции из...
views.py после выполнения функции сервиса, дополнительно отправляем уведомления или...
Views.py два раза, помойму должен быть контроллер
Тоже несколько раз перечитал, но похоже, что так и запланировано. Смотри получили запрос во view. Вызвали serializer, в котором почистили данные. Передали чистые данные в model, создали подключение в Utils, и с помощью helpers, вероятно, отправили в базу, и, если все успешно, вернулись опять во view, в котором отправляем email или message перед возвратом response.
Суть в том, что вся схема изначально, как и изобретение функтора во второй половине статьи говорит о том, что понимание Django у разработчиков описываемого кода не очень, собственно, как и Тестов.
И за такой базар могу ответить: переведи они тесты на DjangoTestCase, Django.SimpleTestCase - нытья про долгий старт быть не должно, как про суммарную скорость выполнения тестов. Хотя это им особо не важно, это не 43 минуты ожидания в четыре потока: на последнем проекте было, бесило страшно.
Назвать Unit.тестом тестирование нескольких sideeffects сразу язык не поворачивается, и беспокоит мысль: что ж за ка-ка-фония у них творится в реальной функции/методе?
По использованию django в статье все выглядит, что пользуются в основном drf, мучаются, но продолжают грызть юзать, опять же, без особого понимания: Там кое-где фильтры прям в коде проскакивали, аж больно смотреть.
Хотя чего я брюзжу. Если самолет у автора не падает, то значит он все правильно сделал. И любой критикан, как я, идет посрамленный, потому как у меня самолета нету. Даже игрушечного. :)
Спасибо, интересный комментарий)
И за такой базар могу ответить: переведи они тесты на DjangoTestCase, Django.SimpleTestCase - нытья про долгий старт быть не должно, как про суммарную скорость выполнения тестов.
Ну с одной стороны так, с другой нет. Если брать только скорость, то да, вполне вероятно отказ от pytest пошел бы на пользу, а еще можно было бы использовать setUpClass вместе с setUp было бы вообще быстро. Только в реальности это приводит к тому что появляются тесты которые не проходят с первого раза, это и была одна из проблем. Аргументом обычно тут служит что то в роде: "пишите хорошо, не пишите плохо, хороший разрабочик должен уметь" и мне этот аргумент нравится, но он хорошо работает в маленьких проектах. Когда распространить на всю компанию, где есть и очень опытные разработчики и новички, где есть как внутренние сотрудники, так и внешние подрядчики, становится очень сложно поддерживать любые решения которые требуют большей экспертизы.
В итоге получается что для нас это работает не потому что это самый правильный способ писать тесты, а потому что этот способ позволяет упрощать тесты и упрощать проверки, что дает плюс в рамках большой компании.
По использованию django в статье все выглядит, что пользуются в основном drf, мучаются, но продолжают
грызтьюзать, опять же, без особого понимания: Там кое-где фильтры прям в коде проскакивали, аж больно смотреть.
И вот тоже интересный момент. С одной стороны да, клево когда встречаешь код, где все проверки доступа в permisssion_classes, а вся фильтрация в filter_backends или filterset_class, но для меня всегда была главной сложностью подгонка задачи под эти либы и подходы. Я не спроста написал именно подгонка задачи, потому что сложность появляется не там где мы просто получаем список, а когда к этому добавляются какие то не стандартные фильтры, или проверки. Чем больше задача отходит от простых CRUD операций тем сложней использовать любые generic подходы, проще фильтрацию в filter_queryset засунуть. С другой стороны это все отлично работает на простых CRUD операциях, там мы от этого не уходим и стараемся делать по канонам.
Привет, спасибо за спасибо. Более чем согласен, что стандарты и контекст организации на проект влияют сильно больше, чем условности использования выбранного Framework. И менять стандарты это точно не вариант, принимаю полностью.
Я просто уже много лет докладываюсь на конференциях о том, что стоит прекратить писать на Python в Django-проектах, и стоит начать писать на Django и будет всем счастье. Все потому, что в 99% случаев в Django-проектах я вижу в способы написать код по-своему, хотя:
В Django это уже есть. Достаточно сделать один import.
Благодаря community это протестировано.
Часто (не всегда) это в Django написано лучше или буквально так же. Последнее прям боль какая-то. DRY весь промок от слез.
Все, что мне остается, это сушить DRY и писать комментарии в стиле: RTFM! В смысле, посмотрите в Django, там уже это есть начиная с версии 0.9 :'(
Тут основная идея в том что часто бывает что поток после выполнения каких то действий в сервисах, потом что то еще доделывают во views.py до возвращения ответа. Такое часто бывает если вынесли только сложную часть логики за пределы view. Собственно danilovmy правильно написал.
Усложнение кода ради того, чтобы не писать моки, того не стоит. В данном случае решение - более удобный интерфейс для моков, например, все вызовы к селери можно ловить вместе и потом проверять список пойманных.
На самом деле не только для упрощения моков, просто в статье на это упор, как на проблему актуальную для всех. Другие плюшки это:
- общий подход к написанию кода между разными проектами. Это очень актуально когда разработчиков и проектов много, все привыкли писать по разному и вот этот подход часть стайлгайда в компании. Получаем единый подход у всех.
- проще работать со сложными процессами. Часто у нас нет технически сложного кода, но есть много сложных и длинных процессов. Такой подход позволяет используя композицию, разделять большие процессы на маленькие. Да, можно и без него, но я попробовал и оказалось что там сильно удобней
С виду очень похоже на стандартную структуризации проекта по схеме Extract/Transform/Load. Поколения разработчиков бизнес приложений приходит к одному и тому же сценарию, немного по разному оформленному. Отдельно функции загрузки данных, отдельно чистые функции преобразования и отдельно сохранение.
Как решить типичные проблемы Django нестандартным подходом: Fake Injection