Да согласен, иногда очень сложно читать запросы написанные ORM поэтому отчасти и был написан этот пакет. Так как джанго для меня гораздо более читабилен чем алхимия.
Из такого что лично мне не хватает: – Это сложные джойны когда не только по зависимостям, плюс вроде правый джойн сейчас не до конца работает (сейчас корректно работает связь от родительской модели до детей). – Подзапросы
Я планирую это добавить в ближайшее время. Но если что то не хватает именно в вашем случае, расскажите пожалуйста. Постараюсь добавить!
По поводу разработки – первая версия наверное около 11 месяцев назад вышла, тогда еще вроде агенты не были распространены или я просто их не так сильно использовал. Я тогда заложил правила интерфейсов, базовые запросы и так далее. Потом где то месяцев 10 у меня руки не доходили что б довести все до ума. В прошлом месяце я решил что пора уже доделать и с помощью клод кода добил - недостающий функционал =)
Согласен, скорость выполнения была не достаточно раскрыта. Может быть потом еще напишу статью с мнением как это можно ускорить, улучшить.
В моем опыта, зависимость тестов приводила к большим проблемам чем лишняя условная минута выполнения тестов. Особенно когда ты пишешь тест на новый функционал а он почему то ломает старый тест. И иди потом разбирайся что случилось =)
Нет, в моем случае база поднимается только один раз в начале тестов а удаляются в конце. Перед каждым тестом создаются таблички в БД, а эта операция достаточно быстрая.
Если важна скорость, то можно сделать один тест который будет проверять чистую функцию на разные значения, просто надо его верно построить. Но это потребует внимательности.
Для меня главное чтоб разные тесты были независимые.
Спасибо за комментарий. Я и не пытался рассказать про техническую часть в данной статье, может сделаю это в будущем так как надо очень сильно погружаться в эту тему. Может сделаю потом.
Тут я больше хотел рассказать о вещах с которыми я сталкивался на нескольких проектах в которые я приходил разработчиком. Может это будет кому то полезно.
Тест как полезный для меня лично это который максимально проверяет функционал, учитывает корнер кейсы и минимально использует вещи по типу мокирования, вместо это используя более динамический подход. Ну а главное что он действительно что то проверял и ловил если что то сломалось.
Тесты которые вы прислали не плохие. Из пожеланий наверное я б убрал чистку в автоматические фикстуры вместо явного вызова их в методах. И явную проверку что БД действительно создаются строчки и полную проверку ответов.
Да согласен, иногда очень сложно читать запросы написанные ORM поэтому отчасти и был написан этот пакет. Так как джанго для меня гораздо более читабилен чем алхимия.
Из такого что лично мне не хватает:
– Это сложные джойны когда не только по зависимостям, плюс вроде правый джойн сейчас не до конца работает (сейчас корректно работает связь от родительской модели до детей).
– Подзапросы
Я планирую это добавить в ближайшее время. Но если что то не хватает именно в вашем случае, расскажите пожалуйста. Постараюсь добавить!
По поводу разработки – первая версия наверное около 11 месяцев назад вышла, тогда еще вроде агенты не были распространены или я просто их не так сильно использовал. Я тогда заложил правила интерфейсов, базовые запросы и так далее. Потом где то месяцев 10 у меня руки не доходили что б довести все до ума. В прошлом месяце я решил что пора уже доделать и с помощью клод кода добил - недостающий функционал =)
Спасибо за комментарий!
Если будет обратная связь - что исправить/что улучшить поделитесь. Постараюсь быстро внести изменения.
Согласен, скорость выполнения была не достаточно раскрыта. Может быть потом еще напишу статью с мнением как это можно ускорить, улучшить.
В моем опыта, зависимость тестов приводила к большим проблемам чем лишняя условная минута выполнения тестов. Особенно когда ты пишешь тест на новый функционал а он почему то ломает старый тест. И иди потом разбирайся что случилось =)
Нет, в моем случае база поднимается только один раз в начале тестов а удаляются в конце. Перед каждым тестом создаются таблички в БД, а эта операция достаточно быстрая.
Если важна скорость, то можно сделать один тест который будет проверять чистую функцию на разные значения, просто надо его верно построить. Но это потребует внимательности.
Для меня главное чтоб разные тесты были независимые.
Спасибо за комментарий. Я и не пытался рассказать про техническую часть в данной статье, может сделаю это в будущем так как надо очень сильно погружаться в эту тему. Может сделаю потом.
Тут я больше хотел рассказать о вещах с которыми я сталкивался на нескольких проектах в которые я приходил разработчиком. Может это будет кому то полезно.
Тест как полезный для меня лично это который максимально проверяет функционал, учитывает корнер кейсы и минимально использует вещи по типу мокирования, вместо это используя более динамический подход. Ну а главное что он действительно что то проверял и ловил если что то сломалось.
Тесты которые вы прислали не плохие. Из пожеланий наверное я б убрал чистку в автоматические фикстуры вместо явного вызова их в методах. И явную проверку что БД действительно создаются строчки и полную проверку ответов.