Добрый день! Какой есть удобный способ тестировать и писать запросы

через ORM? Я на текущий момент захожу в django shell и каждый раз импортирую нужные модули после чего могу приступить к написанию, а в случае внесении правок в модуль все приходится делать повторно. Это не быстро и не удобно, есть лучший способ?

Делать как белые люди - писать автотесты.

Это если уже все написано и есть что проверять, а я еще не набил руку в обращении к ORM, иначе говоря сам запрос еще пока вызывает трудности.

ммм, нет. Гугли TDD

что простите?

test driven development

Разработка через тестирование если я не ошибаюсь.

А, понял о чем речь. Да, разработка через тестирование. Все равно к этому тоже надо приийти, освоив сначала базу.

Если ты экспериментируешь с кодом джанги, то shell тебе будет достаточно. Если же, как ты говоришь, тебе приходится перезагружать его все время, то значит что у тебя там уже не просто отдельные строчки кода, а блоки с какой-то логикой. На этом месте у тебя 2 пути: либо ручками проверять их работоспособность, например на дев сервере или дебаггером. Либо итеративный подход через автотесты.

кстати, метод релоад, работает? не проверяли?

А это вот не в курсе

shell имеет св-во закрываться. как вариант - tracing.py в нем устанавливаешь окружение как в manage.py далее django.setup() и потом импорты моделей и запросы вариант 2. тесты пишем, но раннер тестов переопределяем так, чтобы каждый раз не пересоздавал бд, получается как вариант 1 пихчарм еще и позволит из ide по одному запускать

> shell имеет св-во закрываться. Скорее всего ты имел в виду закрытие соединения с БД. Просто сам по себе shell не закрывается. Соединение можно там же пересоздать. > tracing.py Зачем? В шелле можно включить дебаг мод чтобы вызывать ipdb на исключения > но раннер тестов переопределяем Не надо переопределять раннер. Достаточно просто запускать с ключиком keepdb

Я имел в виду что шел сам закрываешь бывает и часто импорт не из одной строки и идею проверить и многострочный код запихать надо затем что выше, что если что можно вернуться, даже если закрыл ide с ключиком keepdb на прод базе не пробовал чтобы при этом было уже наполнение и можно было прогнать тест хотя прогресс не стоит на месте

По первым двум пунктам я как раз и понял что надо писать тесты. Т.е. это выраженные повторяющиеся действия требующие автоматизации. https://docs.djangoproject.com/en/3.1/ref/django-admin/#cmdoption-test-keepdb

Первые 2 пункта это проверить гипотезу быстро не в 2 строки, shell субъективно уеб-кий

посмотрел, keepdb еще крутить настройки все равно придется чтобы подкидывать бд не тестовую, и keepdb снесет при повторном исполнение предыдущее наполнение вне теста скорее всего teardown_databases еще зачищает чета уже лень ковырять, короче ниче не поменялось зачем это все нужно? в идеальном мире все пишут тесты сразу, бд небольшая и все зачипись юзеры счастливы но бывает что база уже набита, проект старый юзер кидает что его емейл не але и чтобы не писать у нас с тестами все ок а вы козлы делается слепок бд и гоняем orm по его мылу и гипотезы почему отвалилось, и чтобы каждый раз не ждать пока прогонится наполнние на живой базе потыкали тест все ок и уже закинули в CI пусть там себе тормозит

Ты какую-то жуть описываешь. Так-то одна из основных идей тестирования это максимальная изоляция случая. После того как ты такой вот баг нашел, надо написать уже нормальный тест который его покрывает чтобы зафиксировать что в будущем такого не случится и отслеживать регресс кода. И не обязательно локально прогонять несколько тысяч тестов - ты можешь выбрать какие именно тебе нужны - на уровне отдельного пакета, модуля или даже метода.

такое чувство что никогда с легаси не сталкивался -могу только позавидовать

Скорее наоборот - у меня за 5 лет только один проект был который я сам начал с нуля. Никогда даже в голову не приходило писать тесты против "боевого" дампа.

офтоп пошел, я как раз часто пытался реанимировать то что переписывать заново еще денег нет или уже нет