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