Комментарии 22
Шоты работают прям с живой базой данных? Или все же слепок с нее?
Да, шоты работают на живой базе.
Суть тестирования на шоте — проверка работоспособности задачи в боевом окружении. Слепок боевой базы в проекте наших масштабов огромен, это работа не одного сервера.
Если же взять только кусок базы, то проверка почти не будет отличатся от проверки на девеле.
Суть тестирования на шоте — проверка работоспособности задачи в боевом окружении. Слепок боевой базы в проекте наших масштабов огромен, это работа не одного сервера.
Если же взять только кусок базы, то проверка почти не будет отличатся от проверки на девеле.
такой подход, конечно, привлекателен, но я чет не решился бы тесты гонять на боевой базе
Ваши опасения понятны. Но в данном случае суть в том, что все пользователи, которые участвуют в тестах, тестовые. И QaApi может работать только с ними. Это все служит надежной защитой «от дурака».
Тогда смысл шотов пропадал бы.
А если сделать дамп боевой базы и развернуть её на тестовом сервере. Мы в компании так всегда делаем. Если конечно в этом есть потребность.
я так понимаю, там огромная база, которую просто так не сдампаешь в разумные сроки
Вы реально представляете дамп базы Баду? Это далеко не один сервер… Это нехилая такая ферма…
Я не спорю, но а если к примеру специально для тестирования развернуть и 1 раз в пару недель обновлять её? Пусть даже во время тестирования будет не самая свежая версия, но даже в пару недель будет уже неплохо. А по поводу серверов, то думаю у такого монстра как Баду есть парочку свободных ну или арендовать в дата центре? (я не знаком с их внутренней структурой, поэтому это только предположения и вопрос к более опытным людям) ^_^
Еще раз задам вопрос — вы размеры кластера представляете? Получается что просто так держать такую ферму — это просто дико не выгодно по деньгам. Чисто экономически. Ну это как гуглу сказать — так вы бэкап своего индекса сделаейте и на нем эксперементируйте новые логики построения индекса вместо того чтобы на живой базе :).
Давайте я расскажу чуть подробнее. Badoo — это не несколько баз данных в mysql. Badoo — это два (почти три) полноценных датацентра. Это довольно сложная система репликации и шардинга. Плюс фото и мемкешы, система переводов, различные демоны и так далее. И все это дело каждый день улучшается, меняется, ломается и чинится. Бегут какие-то альтеры, какие-то селекты, тестовые инстансы демонов и АБ-тесты. Одним словом — разрабатывается.
Следовательно, первое, что приходит в голову — для поддержания копии всей этой системы даже для одного шота точно так же потребовалось бы два-три датацентра. Второе — будет ли работоспособность нашей задачи в устаревшем окружении гарантировать ее работоспособность в будущем, в актуальной? Очевидный ответ — нет. И вся наша затея становится бессмысленной.
Такие дела.
Следовательно, первое, что приходит в голову — для поддержания копии всей этой системы даже для одного шота точно так же потребовалось бы два-три датацентра. Второе — будет ли работоспособность нашей задачи в устаревшем окружении гарантировать ее работоспособность в будущем, в актуальной? Очевидный ответ — нет. И вся наша затея становится бессмысленной.
Такие дела.
Наши базы данных крутятся примерно на 300 серверах, причём это только пользовательские данные. Они конечно дампятся раз в какое-то время, но даже просто развернуть такой дамп (при условии, что вы уговорили начальство купить ещё 300 лишних серверов) будет требовать несколько суток.
А действительно ли вам нужны полноценные интеграционные тесты с facebook'ом, не рассматривали ли вы возможность замены facebook'а на соответствующий mock?
Mock не поможет если API FB изменится и что-то сломается.
Да, если измениться FB API, полноценные тесты это конечно зафиксируют, но если такая ситуация действительно случится, то о том что что-то сломалось вы скорее узнаете не из тестов, а из массовых ошибок аутентификации/регистрации на проде=)
Ну и кроме того, API никогда не должен изменяться. Как правило при доработках API выпускается его новая версия, которая работает параллельно текущей версии, а не заменяет ее. Ну а так как это все таки FB, то отвалившийся API это что-то крайне редкое и странное. Ну и добивает всю эту ситуацию то, что даже если вы обнаружили данную проблему с помощью тестов, то вы вряд ли сможете с этим что-то сделать, ну если только в техническую поддержку FB'ука написать…
Ну и кроме того, API никогда не должен изменяться. Как правило при доработках API выпускается его новая версия, которая работает параллельно текущей версии, а не заменяет ее. Ну а так как это все таки FB, то отвалившийся API это что-то крайне редкое и странное. Ну и добивает всю эту ситуацию то, что даже если вы обнаружили данную проблему с помощью тестов, то вы вряд ли сможете с этим что-то сделать, ну если только в техническую поддержку FB'ука написать…
Используя mock не будем ли мы тестировать тестовую логику?
Методы, которые формируют запросы к сторонним сервисам, довольно сложные в плане зависимостей и количества условий. Если там что-то сломается, а мы замокаем ответ от FB, мы не поймаем проблему на стейджинге.
А ловить отказ одного из основных способов регистрации/авторизации на продакшене по графикам того, сколько реальных пользователей не смогло попасть на сайт — попахивает письмом с заголовком «WTF??» всем нам на рабочую почту. :)
Методы, которые формируют запросы к сторонним сервисам, довольно сложные в плане зависимостей и количества условий. Если там что-то сломается, а мы замокаем ответ от FB, мы не поймаем проблему на стейджинге.
А ловить отказ одного из основных способов регистрации/авторизации на продакшене по графикам того, сколько реальных пользователей не смогло попасть на сайт — попахивает письмом с заголовком «WTF??» всем нам на рабочую почту. :)
> Используя mock не будем ли мы тестировать тестовую логику?
К сожалению, с mock'ами всегда имеется такая проблема=/ Мне вообще всегда довольно сложно дается ответ на вопрос использовать их или нет. Обычно для этого я задаю себе вопрос: «а что конкретно я тут тестирую??» и тогда решение дается проще. Если в вашем случае запросы к сервисам действительно имеют кучу параметров, то ваш текущий способ конечно же полностью оправдан.
Но все же, в случае регистрации/аутентификации через FB, параметров должно быть минимум. Я правда никогда не работал с API FB, и вероятно сильно ошибаюсь, но для меня эта ситуация кажется странной.
К сожалению, с mock'ами всегда имеется такая проблема=/ Мне вообще всегда довольно сложно дается ответ на вопрос использовать их или нет. Обычно для этого я задаю себе вопрос: «а что конкретно я тут тестирую??» и тогда решение дается проще. Если в вашем случае запросы к сервисам действительно имеют кучу параметров, то ваш текущий способ конечно же полностью оправдан.
Но все же, в случае регистрации/аутентификации через FB, параметров должно быть минимум. Я правда никогда не работал с API FB, и вероятно сильно ошибаюсь, но для меня эта ситуация кажется странной.
Вот пример: вы сделали некий функционал который использует 50% API фейсбука. Написали тесты, всё окей. Выкатили в продакшин… через неделю добавили новых функций по старым мокам (моками покрыли старую версию всю целиком), написали тесты, тесты прошли, выкатили в продакшин — новая часть функционала не сработала — появились жалобы.
> вы сделали некий функционал который использует 50% API фейсбука
ИМХО, в таком случае уже появляется другая проблема — selenium для таких целей не очень подходит.
Фактически мы проверяем что сторонний API работает так как мы ожидаем. В этом конечно нет ничего плохого, но в данном случае лично я бы проверял именно ответы API, а не работу системы с данным API.
PS: Я просто пытаюсь рассуждать, не сочтите что я с вами спорю.
ИМХО, в таком случае уже появляется другая проблема — selenium для таких целей не очень подходит.
Фактически мы проверяем что сторонний API работает так как мы ожидаем. В этом конечно нет ничего плохого, но в данном случае лично я бы проверял именно ответы API, а не работу системы с данным API.
PS: Я просто пытаюсь рассуждать, не сочтите что я с вами спорю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тестируем взаимодействие с Facebook