Начну с того, что понимаю, что в 99,9999% случаев этого следует избегать. Однако я считаю, что у меня есть действительный сценарий использования.
Мы - большая компания с огромным кластером MySQL, в котором хранятся миллионы записей, которые я не знаю даже сколько миллионов. столов. Мы пишем приложение Django, которое обращается к 4 схемам в кластере, что составляет около 100 таблиц. Мы никогда не пишем в эти таблицы, а только читаем из большого их сечения.
Я использовал Django для машинного генерирования неуправляемых классов ORM только для чтения для этих таблиц, и это прекрасно работает на практике .
Все, что мне нужно, - это один тест, который попадает в конечную точку REST и проверяет, отвечает ли он 200 OK. Мне не нужны никакие тесты, потому что через 6 месяцев мы полностью уходим от этого источника данных.
У нас нет доступа на запись к этим данным. Количество усилий по обеспечению безопасности и администрированию, которое нам нужно было бы go пройти, чтобы иметь возможность изменить один байт данных в кластере, представляло бы недели встреч и обсуждений, и тогда мы были бы отклонены. Если мы напишем код для добавления, обновления или удаления данных из этого источника, произойдет сбой.
Я никак не могу потратить время на локальный запуск MySQL для всех наших разработчиков на уровне конечных и внешних интерфейсов, ломать их в нашу систему CI / CD, заставить их встать на сотни столов и загружаю десятки тысяч сложных записей, просто чтобы сказать мне, что для этого небольшого теста моя конечная точка отвечает с 200 OK.
Для меня должно быть возможно, как бы я ни ошибался, сказать Django тестовый бегун "для этого теста, поговорите с производством".