Как тестить скрипты и не ломать данные?

Базу в докере поднимаешь, набиваешь данными и тестишь что хочешь. Апишки сложнее, надо мокать. Но в целом тоже ничего сверх

Надо разобраться с понятием мока и все станет норм. Посмотри другие проекты с авто тестами на твоём яп

Во первых да, разобраться с понятием мока, как пишут выше. Во вторых в рубях (и подозреваю что в питоне) есть такая либа, которая позволяет сделать один реальный запрос удаленному урл и получить реальный ответ, после чего все последующие разы (даже если тесты запускаются по новой) вместо ответа от УРЛ-а он тебе будет отдавать сохраненный ответ от УРЛ-а. В руби этот гем называется «vcr» если что (типа «virtual cassette recorder» кажется). У обоих подходов (mocks vs vcr) есть свои плюсы и минусы, но это уже надо прочувствовать, я думаю.

Подёргать файлики

Программы работают с файлами в каком-то каталоге. В тестовом режиме просто указываешь песочницу вместо директории с промышленными данными. Например /tmp/foobar.

публичным api

Все то же самое, что и с файлами — вместо https://api.google.com указываешь заглушку (mock). Например http://localhost:8888. На localhost:8888 ты можешь поднять симуляцию гуглового API, например, сделанную на том же Питоне на коленке.

Еще вариант. Допустим твой код выглядит так

class ApiClient:
    def call_google(self):
        response = http.get('https://api.google.com')
        return {'foo': response.foo, 'bar': response.bar}

c = ApiClient()
parse(c.call_google())

class ApiClientMock:
    def call_google(self):
        return {'foo': 'simulated value', 'bar': 'simulated value'}

c = ApiClientMock()
parse(c.call_google())

API мокать.

Бд мокать я лично не вижу смысла, лучше написать код, который генерирует тестовые данные. От этого польза будет двойная: легче поднимать тестовые стенды или делать очистку и детерминистичная основа для тестов (то есть тесты могут со 100% уверенностью ожидать некоторые данные).

А тесты с реальной бд можно вообще по-разному запускать. Можно всё держать в транзакции, а при завершении теста откатывать её. Можно под каждый запуск тестов создавать чистый контейнер. Опций много, но я бы шёл по пути наименьшего сопротивления, чтоб не овер-инжинерить. Главное не запускать тесты с произвольным состоянием бд - это подрывает саму идею.

поднять симуляцию гуглового API, например, сделанную на том же Питоне на коленке.

Это пока предел моих умений, наколенить буду дольше чем то что нужно потестить 😁

С моками стало чуть понятнее, спасибо)

В руби этот гем называется «vcr»

qount_25 есть питон-версия. Классная штука, отправил в закладки. У меня апи не меняется (по крайней мере пока). А вот файлики непредсказуемые прилетают - в любой момент может что-то добавиться или переместиться, либо вообще есть аномальные случаи когда нужных данных вообще нет.

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

Вроде в голове более-менее всё встало, спасибо всем отписавшимся. Пойду читать. 😊