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

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

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

Во первых да, разобраться с понятием мока, как пишут выше. Во вторых в рубях (и подозреваю что в питоне) есть такая либа, которая позволяет сделать один реальный запрос удаленному урл и получить реальный ответ, после чего все последующие разы (даже если тесты запускаются по новой) вместо ответа от УРЛ-а он тебе будет отдавать сохраненный ответ от УРЛ-а. В руби этот гем называется «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 есть питон-версия. Классная штука, отправил в закладки. У меня апи не меняется (по крайней мере пока). А вот файлики непредсказуемые прилетают - в любой момент может что-то добавиться или переместиться, либо вообще есть аномальные случаи когда нужных данных вообще нет.

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

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

Using stable element locators ensures your tests function consistently and avoid unexpected failures due to minor changes in the page’s structure. Test scripts relying on unstable locators are vulnerable to breaking with minor changes in the application’s underlying code This way, when any changes occur to the software application, you would not need to update multiple tests, you would just have to update the part of the script that needs to be changed https://spacebarcounter.org/