Ага. т.е. там где мы раньше писали User.objects.create(name='jake'), теперь можем написать UserFactory(name='jake')

Через Faker можно создать нужное количество User с разными именами

Через Faker можно создать нужное количество User с разными именами

через factory_boy тоже

Но не в том суть.

И по идее, https://docs.djangoproject.com/en/1.11/topics/testing/tools/#fixture-loading , Django что-то такое умеет.

Вот в чем суть.

Но, блин, нифига не работает.

И вот.

Я про связку. Щас напишу как

Потом бах-трах, loaddata

я представил сейчас, как мой CI выглядел бы, где мы берем 20 гб дамп, бам-трах грузим его в CI, тестим, потом сносим...и это каждые N минут

я представил сейчас, как мой CI выглядел бы, где мы берем 20 гб дамп, бам-трах грузим его в CI, тестим, потом сносим...и это каждые N минут

Фантазия это хорошо, безусловно. Она Вам сейчас поможет. Смотрите. У нас есть базовая структура. Мы создаем в ней минимальный набор данных. Далее, делаем дамп, который и используем потом для тестов.

Представляете?

Далее, представим, что у нас какая-то фича с некоторыми миграциями....ты льешь свой дамп, далее ты обязан во время тестов накатывать миграции все, потом только сможешь протестировать фичу, иначе она свалится из-за бд

Фантазия это хорошо, безусловно. Она Вам сейчас поможет. Смотрите. У нас есть базовая структура. Мы создаем в ней минимальный набор данных. Далее, делаем дамп, который и используем потом для тестов.

зачем этот лишний шаг то? Есть базовая структура в фикстурах, которая создает набор данных, который используется для тестов

Далее, представим, что у нас какая-то фича с некоторыми миграциями....ты льешь свой дамп, далее ты обязан во время тестов накатывать миграции все, потом только сможешь протестировать фичу, иначе она свалится из-за бд

тестовая бд разве не создается с последней миграции?

https://pastebin.com/ZGjUHmXu

Как-то так. Потом UserFactory.create_batch(1000)

И тебе создаст 1000 юзеров с рандомными name

Как-то так. Потом UserFactory.create_batch(1000)

Спасибо, но как я уже и сказал, меня не интересует подобное.

Причём сразу сказал

Что не нужны мне фабрики

хоть они 1 лям генерят.

Я могу юзать фабрики, не отрицаю

и это выход, оно будет работать

и есть решения удобные для них

и это здорово\полезно

но сейчас

меня интересуют именно фикстуры

джанговские

и их импорт в тесты.

Вы чет не так делаете. Вместо схемы: ответ на вопрос, предложение сделать лучше и обоснование - Вы делаете - предложение сделать лучше.

Упускаете две важные части

Одну из них критически важную.

Одну из них критически важную.

Просто нужно делать лучше

?

Воот, так вопрос тоже без обоснования, почему надо делать через одно место, а не по best practices? Или я упустил это обоснование?

Не понимаю, в чем смысл подтягивать фикстуры для тестов

Воот, так вопрос тоже без обоснования, почему надо делать через одно место, а не по best practices? Или я упустил это обоснование?

от чего же. Я вижу в этом неплохое решение моей конкретной задачи. Которое объективно лучше (в том виде, как я это себе представляю, не работает же). И кода меньше и производителность не страдает.

+ без сторонних расширений

+ у Django из коробки что-то подобное есть.

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

Я вижу пока только больше кода, причем костыльного

+ без сторонних расширений

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

Это каждый раз заливать дамп в тестовую базу? Бред какой-то

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

1. Код на создание дампа - это одна команда в консоли. Которая делается по мере роста функционала и легко редактируется (допустим, выпилить 10кк объектов двумя кликами); 2. Код на его загрузку - отсутствует, если верить документации; 3. Берется, когда тестируется новый функционал. Путем ввода ручками одной комманды в консоли и, возможно, два клика для небольшого редактирования дампа;

Так так так Вот погоди Сам дамп то как генерируется?

тот самый файлик users.json, к примеру

ручками))

и как чувак, вводящий с фичей новое текстовое поле в модели User обновляет этот файлик?

добавили поле description, где надо генерить некоторое количество символов, скажем 500 текста

manage.py dumpdata, открываем созданный файл, оставляем по 10-20 записей, нужных нам (для моей задачи - секунд 60, если смотреть телек параллельно). И, профит, не?

Они все отсортированы

убить хоть 10кк не проблема же

Бля, редактировать дамп с 10кк

Мсье Вы знаете толк

>смотреть телек никакого профита, абсолютно

manage.py dumpdata, открываем созданный файл, оставляем по 10-20 записей, нужных нам (для моей задачи - секунд 60, если смотреть телек параллельно). И, профит, не?

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

и только потом запустить тесты!

Такс, ребят. Я Вас прекрасно понимаю.

Я спросил о существуеющей у Джанги технологии

Мне никто, ничего не объяснил.

Но

Но!

Я спросил о существуеющей у Джанги технологии

Я думаю таким никто не занимается

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

Накидали over90000 вариантов, как сделать иначе.

Ок, я Вас понял.

Не вижу смысла продолжать дискуссию.

Я спросил о существуеющей у Джанги технологии

да, мы же рассказали тебе про фабрики в фикстурах и прочие вещи

Да-да

Рассказали

Потом ещё рассказали

Я пошел.

Пасиб

ну погоди, я ведь пытаюсь понять, как ты это делаешь, чтоб понять причину твоего непонимания и непринятия

Не-не, прости. Я сам разберусь.

ну погоди, я ведь пытаюсь понять, как ты это делаешь, чтоб понять причину твоего непонимания и непринятия

Как как. Ты же уже понял что руками

извини, если мои вопросы показались грубыми, но этот способ тестирования очень странно выглядит в моем понимании

Я ведь, скорее всего, буду юзать фабрики, ведь это действительно эффективно и полезность сего решения возрастает с увеличением функционала сервиса.

Не-не, прости. Я сам разберусь.

хорошо, прошу прощения http://blog.qax.io/complex-pytest-django-example/ вот примерчик простой теста

https://michaelvdw.nl/code/adding-pytest-to-your-django-project/ и вот еще туда же

> complex > простой ))))

все как мы писали - с пайтестом и фабриками, best practices

> complex > простой ))))

название не соответствует содержанию :)

Теперь привыкать к новой аватарке @amureki ...

Теперь привыкать к новой аватарке @amureki ...

простите, я решил пододвинуть котов :)

Хочу взять, dumpdata

dumpdata в реальной жизни не работает, потому что обычно базы с овердофига данных, там не получится использовать такую команду... я вообще удивляюсь, что её не удалили

dumpdata в реальной жизни не работает, потому что обычно базы с овердофига данных, там не получится использовать такую команду... я вообще удивляюсь, что её не удалили

На этапе разработки - удобно. Ну, пока. Мне.

Я даже не сам к ней пришел. Кто-то подсунул

Мол, сделай фикстуры.

Я такой, ок

ну, в общем, она нормально работает, только если это какая-то пустая тестовая база, а если production - там так или иначе будет SQL

а loaddata в тестах можно вызвать как команду

но, опять же, возможно, sql будет удобнее

но, опять же, возможно, sql будет удобнее

О чем сырбор идет?) Привет!

а я не знаю

?)

ну, в общем, fixture удобно использовать для создания тестовых данных) и там из тестов можно выполнять loaddata, а вот применение dumpdata я не увидел, мне кажется это ненужным, дампить лучше в SQL тогда уж и если есть такая потребность, то и fixture тоже переводить в SQL тогда

мне кажется, в будущем эти fixtures вообще выкинут из Django

но я не уверен

На сложных базах у меня никогда не выходило нормально сдампить и слоадить через эти команды через бд дампы делал всегда в итоге