TK
получается, при каждом прогоне тестов создавать такую вспомогательную базу ?
Size: a a a
2018 October 26
A(
Может лучше реализовать дамп какой ли бо базы на нем выполнить проверки и потом удалить этот дамп и так по кругу?
Вариант с дампом хороший, только если не тестируется продакшн.
EK
ага
TK
вообще, объем тестов небольшой, ~ 50-70 штук
EK
в моем понимании это уменшит нагрузку на апи (-1 запрос в каждом тесте)
EK
ну если ваш проект растет, то их будет становиться все больше и больше, а потом переписывать все тесты будет не очень приятно
A(
получается, при каждом прогоне тестов создавать такую вспомогательную базу ?
Если у вас тестовая база, то проще просто держать бэкап "чистой базы". После тестов накатывать его.
Если прицел так же на тестирование продакшна - то здесь нужен дамп, без вариантов.
Если прицел так же на тестирование продакшна - то здесь нужен дамп, без вариантов.
EK
Если у вас тестовая база, то проще просто держать бэкап "чистой базы". После тестов накатывать его.
Если прицел так же на тестирование продакшна - то здесь нужен дамп, без вариантов.
Если прицел так же на тестирование продакшна - то здесь нужен дамп, без вариантов.
+1 🙂
TK
к сожалению, у нас пока рабочая база((((( P.S. знаю, что тестить на рабочей базе - зло)
A(
Да не совсем уж и зло. Тестить продакшн тоже надо)
TK
надо, но аккуратно 😁
A(
к сожалению, у нас пока рабочая база((((( P.S. знаю, что тестить на рабочей базе - зло)
Но от варианта "после теста возвращаю данные как были" стоит отказаться. Хотя бы по той причине, что когда-то, в какой-то момент это не отработает и у вас в продакшне будут левые тестовые данные со всеми вытекающими последствиями)
MA
всем привет! вопрос по апи тестам. Пример: тест на изменение данных пользователя: делаю post запрос с json'ом, данные изменились, ок. Затем хорошо бы вернуть все как было до выполнения теста, снова отправляю post но с прежними данными. Стоит ли вынести отправку запроса с данными в отдельную функцию? Получится что в тесте вызывается функция, происходит проверка, и снова вызывается функция. Пишу на js + chai mocha.
1. тесты, лезущие в базу должны гоняться только на стейдже.
2. если на стейдже тесты лезут в базу, то беспокоиться о возврате данных не надо, процесс измения данных должен быть зафиксирован
3. если юзер перед каждым тестом должен быть в фиксированном состоянии - пересоздавайте его
2. если на стейдже тесты лезут в базу, то беспокоиться о возврате данных не надо, процесс измения данных должен быть зафиксирован
3. если юзер перед каждым тестом должен быть в фиксированном состоянии - пересоздавайте его
EK
Но от варианта "после теста возвращаю данные как были" стоит отказаться. Хотя бы по той причине, что когда-то, в какой-то момент это не отработает и у вас в продакшне будут левые тестовые данные со всеми вытекающими последствиями)
Я все равно не понимаю, даже если это продакшн, что мешает дампить базу и прогонять тесты? Фактически это же идеальный клон продакшина на текущий момент
A(
Я все равно не понимаю, даже если это продакшн, что мешает дампить базу и прогонять тесты? Фактически это же идеальный клон продакшина на текущий момент
Это как раз и есть стейдж, о чем выше Максим написал)
TK
спасибо за ответы, подумаю насчет дампа БД
MA
спасибо за ответы, подумаю насчет дампа БД
если уж хочется тестами писать в прод базу, то тут я бы подумал не о дампе а о двойном деплое прода сразу на 2 окружения. это когда коммит проходит тесты в пайплайне и деплоится еще и дополнительно на тестовое окружение типа prod1.ru. а вы берете дамп с прода, разворачиваете его на это дополнительное окружение и запускаете тесты вообще не касаясь настоящего прода. некоторые компании категорически запрещают гонять тесты на проде, это как пушить нетестированные фичи в пятницу вечером
TK
лично мне вариант гонять тесты на базу прода не нравится, но у программистов полно своих задач, а я пока не знаю, как все настроить самой (тестами занимаюсь совсем недавно)
TK
но хочется сразу все сделать получше, чтобы в дальнейшем было удобно работать
TK
и не пришлось полностью все переделывать