Предлагаете юзать только стандартную библиотеку без сторонних зависимостей? :) В противном случае, описанные вами проблемы не избежать. И это касается не только данной библиотеки
1. Вместо отдельного файла конфигурации лучше конфигурацию хранить в environment файлах. Так мы избежим ситуации, когда в проде приложение будет работать с моками
2. У класса BaseEndpoint слишком много ответственности: он и обрабатывает логику с фейками, и пропихивает ошибки в error сервис. Напрашивается разделение
3. Советую присмотреться к rxjs.
Поддержу предыдущего оратора. Следуя таким принципам я сделал пакет для мокирования запросов ngx-mock-server. Основная идея — подмена данных происходит на уровне интерсепторов, сами моки конфигурируются на уровне модуля (либо модулей, в том числе lazy модулей) подобно конфигурации роутов.
TestMace не стремится скопировать Postman, я думаю из данной статьи можно сделать такой вывод. Однако признаюсь, что ваш вопрос является наиболее задаваемым, мы даже решили оформить ответ в виде статьи habr.com/ru/post/480734.
По поводу глобального задания домена, как negasus правильно сказал, для данного случая лучше подходят переменные.
Спасибо что проголосовали. Цель TestMace покрывать как можно больше кейсов работы с API. В идеале захватить и нагрузочное тестирование. Но это все таки отдельная и сложная область, слепо копировать конкурентов не хочется, ибо это не совсем ложится в наши концепции. Будем думать)
Конечно умею, я «прицепился» (уж простите) к этой фразе
Зашел взглянуть на ваши — а у вас-то даже и гитхабовский профиль не указан :( Наверное, шикарные рабочие условия мешают?
Прицепился, потому что тут вы перешли на личности, используя к тому же сомнительный (с моей точки зрения) аргумент. Уже не раз поднимался вопрос оценки уровня разработчика по наличию/отсутствию «хорошего» профиля на Github. К единому мнению не пришли. Хотя безусловно, наличие коммитов в OSS проектах хорошо характеризует разработчика, однако отсутствие коммитов мало о чем говорит.
А то есть если у разработчика есть удобное рабочее место, то будь добр иметь приличный гитхабовский профиль? Даже более того, обязательно каждый разработчик должен иметь гитхабовский профиль с коммитами в OSS проекты?)
Народ, го холиварить, я создал.
Ни первое, ни второе пока не реализовано. Но насчет второго мы планируем реализовать в рамках assertion-ов. Насчет первого — мы после импорта храним swagger в нашем внутреннем формате. В дальнейшем рассматриваем возможность экспорта в swagger/openapi, но пока не думали над этим вопросом.
Насчет ui тыкательной автоматизации — в приведенной цитате больше делался упор не на автоматизацию, а на разбиение функционала на независимые части (узлы).
Насколько мне известно, в cf весьма кастрированные воркеры. То есть для умного проксирования подойдёт, но ни в базу сходить (за исключением их kv-хранилища), ни в файл записать у вас не получится.
И повторюсь, в статье речь идет о блокировании приложений, использующих приватный API, а не о некачественности приложений на Electron. Повторите ли вы свой комментарий, в случае, если по этой же причине заблокируют в AppStore, скажем, Telegram? Хотя при таком развитии событий обвинить Apple в непоследовательности будет трудно)
Ну тут получается, что в авгиевы конюшни вы включаете Slack, Skype, VSCode, Google Chrome, Discord?) Вряд ли Apple и его пользователи выиграют, если столь популярным приложениям не найдется места в App Store. Ну ок, будем качать по прямым ссылкам)
It used to work and now it doesn't :-(
Ну и какой-то он не гибкий, навязывает свой API (как бы это странно ни звучало)
1. Вместо отдельного файла конфигурации лучше конфигурацию хранить в environment файлах. Так мы избежим ситуации, когда в проде приложение будет работать с моками
2. У класса BaseEndpoint слишком много ответственности: он и обрабатывает логику с фейками, и пропихивает ошибки в error сервис. Напрашивается разделение
3. Советую присмотреться к rxjs.
По поводу глобального задания домена, как negasus правильно сказал, для данного случая лучше подходят переменные.
Ещё добавлю, что флаги типа strictNullChecks лучше включать на ранних этапах работы с проектом, иначе потом будет больно его "включить"
Это ж как надо расстреливать ноги, чтобы в nodejs нитка, о существовании которой я не подозреваю, дёргала "мои" колбеки?)
Прицепился, потому что тут вы перешли на личности, используя к тому же сомнительный (с моей точки зрения) аргумент. Уже не раз поднимался вопрос оценки уровня разработчика по наличию/отсутствию «хорошего» профиля на Github. К единому мнению не пришли. Хотя безусловно, наличие коммитов в OSS проектах хорошо характеризует разработчика, однако отсутствие коммитов мало о чем говорит.
Народ, го холиварить, я создал.
Насчет ui тыкательной автоматизации — в приведенной цитате больше делался упор не на автоматизацию, а на разбиение функционала на независимые части (узлы).
Здравствуйте, пофиксил проблему с авторизацией на Linux. Теперь процесс авторизации проходит через браузер пользователя
Ага, поняли, приняли, попытаемся воспроизвести