Привет. У нас несколько раз добавлялись разные платежные функции и, на сколько я знаю, банк пару раз менял маски для полей ввода договоров (чем это было вызвано не знаю, это аутсорс и с нами не всегда делятся)
Ааа, вот Вы о чем))
Нет, мы не делаем запросы с экрана. У нас нормальная архитектура с протоколами, сервисами и презентерами (кстати тоже в опенсорсе).
Я просто не стал усложнять описание, потому что то как описано в статье нагляднее и понятнее (если вдруг ее прочтет не мобильный разработчик)
Смотрите, если делать реализацию на клиенте, то есть несколько проблем:
Из-коробки нет способа менять ответы на какие хочется прямо в процессе работы. Это можно сделать, но:
Нужно писать инфраструктуру под это (в приложении)
Нужно переключаться между экранами приложения
Не понятно как это шарить нормально. Разве что иметь общий репозиторий из которого это пулится (моки еще другой команде нужны). Выглядит немного "гвоздями прибито" да и консистентность может нарушаться.
Такое же решение нужно реализовывать для всех используемых платформ (iOS, Android, возможно Web)
Редактировать моки из приложения (да и с телефона вообще) не удобно.
Появляется инвазивность. То есть нам нужно будет делать какие-то потуги, чтобы одно переключить на другое. (сейчас к примеру мы просто один URL на другой заменяем флагами)
Возможность хранить тест-кейсы (как моки) отдельной стройной конструкций (и не трогать разработчиков для их поддержки) тоже пропадает.
Здесь идея как раз в том, чтобы разработчики клиентской части вообще не заморачивались, а писали как пишут. Просто подменяется "реализация" сервера. Поэтому все то, что тестеры обычно проверяют (что будет если запрос обвалится по таймауту, что будет при долгом запросе и т.п.) остается неизменным.
Честно, такое впечатление, что Вы решили свою заглушку докрутить до уровня конструктора бакендов ;)
Как-то даже не думал об этом)
По моему мнению достаточно тестовых данных в объеме для решения двух задач.
Мне кажется это решает только часть проблем при разработке фронта, разве нет? Проблема-то в том, чтобы мобильщик/QA мог что-то там под себя докручивать, что-то по ходу менять. Ну то есть еще очень ценна интерактивность. Ну и в процессы эту штуку можно вписать так, чтобы получить с нее профит при возникновении каких-то форс-мажоров, при ручном тестировании.
Т.е. эмулятор достаточно научить понимать данные...
Мне кажется, что не стоит мешать данные из unit тестов бэка и данные, которые использует для себя фронт. Хотя, возможно, я просто Вас не понял)
У нас упал сервер, так давайте же… напишем свой сервер с блекджеком и!..
Ну ведь делалось это не совсем так, да и это далеко не полноценный сервер)
К слову, не очень понятно что мешает на самом...
Дело же не только в том, чтобы просто замокать. Есть еще интерактивная часть, когда ты меняешь что-то под себя. На моем опыте бэк не сильно-то желал давать кому-то доступы к тем же мокам, а тем более пилить чтение из файлов, чтоб потом его выпилить (может специфично для аутсорса).
К тому же иногда бэка как бы просто нет. Он не просто долго пишется — его нет (пока еще).
Или когда сервер упал. Были кейсы когда уже все выровнялось, но сервак лежал по 3-5 дней (здесь уже моками на дев-сервере не отделаешься). Ну и решение такое почти неинвазивно.
Ну к faker ни как не относится. Если я правильно понял зачем он нужен. А вот json-server это аналог да, но опять же. Вопрос в функциональности. json-server (на сколько мне известно) не позволяет проксировать запрос и сохранять ответ (история про кеширующий прокси), а у этого есть интересный юзкейс — поддержка. Мы используем Mocker как страховочный сервис даже после того, как реальны бек уже есть (дорабатывается). Проксирование позволяет без танцев с бубном поддерживать моки в актуальном состоянии и при этом они структурированно лежат.
Плюс фича с явным указанием пути. Полезно для тестеров, когда нужно протестировать какой-то конкретный кейс или флоу. Таким способом можно как бы "выделить" что-то вроде окружения в котором работа QA не аффектит всех остальных.
Ну и я не знаю как будет вести себя json-server если мы создадим 10 разных моков на один запрос. Будет ли он возвращать их итеративно или это вообще не будет работать (это не пагинация). И может ли он вернуть определенный ответ в зависимости от параметров запроса или тела запроса.
P.S. Спасибо за faker выглядит так, будто его можно прикрутить ко всему этому делу (правда потребность получить кучу случайных данных не часто возникает, но все же)
Не совсем. Postman это конечно одна из альтернатив, но, на сколько я знаю, у него во-первых нет функциональности, которая есть у Mocker, во-вторых (опять же на сколько мне известно) Postman Mock Server в бесплатной версии ограничен по лимитам.
Этот сервис (Mocker) все таки чем-то так или иначе отличается от своих альтернатив
Привет. У нас несколько раз добавлялись разные платежные функции и, на сколько я знаю, банк пару раз менял маски для полей ввода договоров (чем это было вызвано не знаю, это аутсорс и с нами не всегда делятся)
Пробовали, для Unit-тестов.
Ааа, вот Вы о чем))
Нет, мы не делаем запросы с экрана. У нас нормальная архитектура с протоколами, сервисами и презентерами (кстати тоже в опенсорсе).
Я просто не стал усложнять описание, потому что то как описано в статье нагляднее и понятнее (если вдруг ее прочтет не мобильный разработчик)
Смотрите, если делать реализацию на клиенте, то есть несколько проблем:
Здесь идея как раз в том, чтобы разработчики клиентской части вообще не заморачивались, а писали как пишут. Просто подменяется "реализация" сервера. Поэтому все то, что тестеры обычно проверяют (что будет если запрос обвалится по таймауту, что будет при долгом запросе и т.п.) остается неизменным.
Как-то даже не думал об этом)
Мне кажется это решает только часть проблем при разработке фронта, разве нет? Проблема-то в том, чтобы мобильщик/QA мог что-то там под себя докручивать, что-то по ходу менять. Ну то есть еще очень ценна интерактивность. Ну и в процессы эту штуку можно вписать так, чтобы получить с нее профит при возникновении каких-то форс-мажоров, при ручном тестировании.
Мне кажется, что не стоит мешать данные из unit тестов бэка и данные, которые использует для себя фронт. Хотя, возможно, я просто Вас не понял)
Ну ведь делалось это не совсем так, да и это далеко не полноценный сервер)
Дело же не только в том, чтобы просто замокать. Есть еще интерактивная часть, когда ты меняешь что-то под себя. На моем опыте бэк не сильно-то желал давать кому-то доступы к тем же мокам, а тем более пилить чтение из файлов, чтоб потом его выпилить (может специфично для аутсорса).
К тому же иногда бэка как бы просто нет. Он не просто долго пишется — его нет (пока еще).
Или когда сервер упал. Были кейсы когда уже все выровнялось, но сервак лежал по 3-5 дней (здесь уже моками на дев-сервере не отделаешься). Ну и решение такое почти неинвазивно.
Ну к
fakerни как не относится. Если я правильно понял зачем он нужен. А вотjson-serverэто аналог да, но опять же. Вопрос в функциональности.json-server(на сколько мне известно) не позволяет проксировать запрос и сохранять ответ (история про кеширующий прокси), а у этого есть интересный юзкейс — поддержка. Мы используем Mocker как страховочный сервис даже после того, как реальны бек уже есть (дорабатывается). Проксирование позволяет без танцев с бубном поддерживать моки в актуальном состоянии и при этом они структурированно лежат.Плюс фича с явным указанием пути. Полезно для тестеров, когда нужно протестировать какой-то конкретный кейс или флоу. Таким способом можно как бы "выделить" что-то вроде окружения в котором работа QA не аффектит всех остальных.
Ну и я не знаю как будет вести себя
json-serverесли мы создадим 10 разных моков на один запрос. Будет ли он возвращать их итеративно или это вообще не будет работать (это не пагинация). И может ли он вернуть определенный ответ в зависимости от параметров запроса или тела запроса.P.S. Спасибо за
fakerвыглядит так, будто его можно прикрутить ко всему этому делу (правда потребность получить кучу случайных данных не часто возникает, но все же)Этот сервис (Mocker) все таки чем-то так или иначе отличается от своих альтернатив
Она изначально была простенькой и решала небольшие проблемы, а сейчас сильно «растолстела». Собственно, поэтому одной статьей дело не ограничится.