BB 8

Например, вот так:

it('Request', () => {
    cy.server()
    cy.route("POST", '/oauth/token').as('getToken')

    cy.get(['data-cy="button-get-token"]').click()

    cy.wait('@getToken').its('status').should('eq', 200)
  })

В официальной документации вроде описано. Внизу есть и ссылка на пример реализации.

И также в этом гайде официальной документации описаны принципы тестирования с использованием их фреймворка.

https://habr.com/ru/company/mailru/blog/269465/
https://medium.com/front-stories/%D0%BA%D0%B0%D0%B...

var numbers = [1,-3,5,-6,-10,13,4,-8];

var arr = numbers.slice(), sum = 0;
while((sum += arr.shift()) !== 0); // изысканный пустой while !
var index = numbers.length - arr.length - 1;  // 5

Или с рекурсией:

function sum0(arr, idx = 0, sum = 0) {
  if ((sum += numbers[idx]) === 0) return idx;
  return sum0(arr, idx + 1, sum);
}

sum0([1,-3,5,-6,-10,13,4,-8])  // 5

Потому что then всегда возвращает promise.
Даже если ты внутри функции resolve напишешь return 42, это then вернёт Promise(42).

fetch(url).then(function(response) {
  return 42;
})

Это работает так по двум причинам.
Первая, чтобы можно было без проблем писать .then().then().then(). Ведь если какой-нибудь then вернёт число посреди такой цепочки, то произойдёт ошибка. Ведь у чисел нет метода then, верно?

(42).then() // => TypeError: 42.then is not a function

Вторая причина, это то что промисы не выполняются сразу. В этом и смысл, верно? Мы создаём цепочку отложенных вычислений по принципу Если произошло это, тогда сделать То, а потом Вот это и т.д. Методу then просто нечего возвращать на тот момент, когда ты его запускаешь. Его запуск только создаёт план действий.

Поэтому, когда ты запускаешь console.log(data), в массиве data лежат промисы. И они даже ещё не начали выполняться на этот момент. Ни одна из функций resolve или reject еще не была запущена.

Код можно поправить так:

'use strict';

let urls = [
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/ETHUSD',
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/LTCUSD',
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/BTCUSD'
];

let data = urls.map((item, index) => {
  return fetch(item).then(function(response) {
    return response.json();
  }).then(function(data) {
    console.log(data);
  }).catch( alert );
})

console.log(data);

Сначала в консоли появится массив промисов, который ты уже видел. А уже через секунду три объекта, которых ты ждал.

Чтобы получить три объекта сразу, в массиве, нужно прибегнуть к либо async / await, либо как писали в других ответах Promise.all. Promise.all(array).then(resolve, reject) ждет выполнения всех промисов в array, и только тогда вызывает resolve или reject для массива ответов или ошибок.

'use strict';

let urls = [
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/ETHUSD',
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/LTCUSD',
  'https://apiv2.bitcoinaverage.com/indices/global/ticker/BTCUSD'
];
let array = urls.map((item, index) => {
  return fetch(item).then(function(response) {
    return response.json();
  }).catch( alert );
});

Promise.all(array).then(console.log);

Promise.all(data).then(console.log);

Хороший кандидат на должность Junior React Developer, по моему мнению, должен соответствовать следующему перечню требований:
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.

Это не красный минимум знаний и во многих компаниях требования могут быть значительно ниже. Но соответствие вышеперечисленым пунктам будет хорошим аргументом для работодателя остановить свой выбор именно на вашей кандидатуре.

Похожий вопрос.

У вас есть какой-то шаблон. Для удобства залейте его на github и все.

Зачем менять имя package.json и описание? У меня в проекте в имени указан просто Vue-template и в описании перечисление технологий, что бы другим было удобно.

Установка шаблона в несколько команд ->

git clone https://github.com/name/project
npm i
npm run serve

И все, работайте.

Для начала хочу поругаться! Ибо наговнокодят, а потом "браузеры тормозят и жрут память"...
1. Никогда не создавайте функции в циклах! НИКОГДА! Тем более однотипные.
2. Никогда не создавайте объект (тем более такой тяжелый как массив), только ради того, что бы дернуть метод его прототипа!
3. К ошибкам... Вы пробовали запускать свой код с пустым localStorage? Попробуйте...
4. Еще к ошибкам... Что будет с Вашими данными, если придет простая таска: "Добавить еще один радио между первым и вторым"?
5. Ну и не к производительности, а к читабельности и поддерживаемости:
Вы сами то разбираетесь в этих Ваших переменных a, b, c, d, e?

Теперь по теме:
input[type=radio] - это переключатель. Среди нескольких радио с одинаковым name выбран может быть только один. Вам нужно хранить не индекс - checked (чем вообще череват индекс - смотрите п.4 в моей критике), а name - value выбранного радио

Что ж, пожалуй поправлю, а заодно порефакторю Ваш код:

(function(selector) {
    // не дублируем код
    function save(data) {
        localStorage.setItem(selector, JSON.stringify(data));
    }
    // и не создаем тысячи функций в цикле
    // а используем одну общую
    function onChange(event) {
        var element = event.target,
            name = element.name,
            value = element.value;
        data[name] = value;
        save(data);
    }
    var elements = document.querySelectorAll(selector),
        data = localStorage.getItem(selector);
    if(data) { // если в сторадже что-то есть
        // то можем и распарсить
        data = JSON.parse(data);
    } else {
        // иначе парсить нельзя, будет ошибка
        // присвоим дефолтное значение и сохраним
        save(data = {});
    }
    // вместо ненужного создания массива
    // обратимся напрямую к прототипу
    Array.prototype.forEach.call(elements, function(element) {
        var name = element.name,
            value = element.value;
        if(data[name] === value) { // если текущий элемент отмечен в сторадже
            // то отметим и на странице
            element.checked = true;
        }
        // навесим созданый вне цикла хандлер на событие
        element.addEventListener("change", onChange);        
    });
})(/* ".stat_inp_r"
  А еще к селектору вопрос, мы только с этим классом радио будем запоминать?
  или же у нас каждый будет помнится?
  если каждый, то может имеет смысл обработать их все за раз:
*/ "input[type=radio]");

Локализуется лицо, полученная картинка нормализуется, затем от неё считается какой-то набор признаков, по всей базе ищутся наиболее похожие на этот объекты, в простейшем случае в качестве ответа берётся самый ближний из них.

Услуги: SaaS-сервисы, консультации/репетиторство, возможность платной публикации материалов, доступ к закрытым статьям и сообществам, и т.д.

Товары: продажа софта/программ, скриптов, баз, электронных книг, видео-курсов, он-лайн курсов, музыкальных произведений, графики, 3D-моделей, видео-роликов, продажа лицензий к софту, доступы к игровым сетям (PSN, Xbox Live), prоxy/VPN, кодов к играм, продажа игровых предметов, доменных имён.

Продажа приоритетов и акцентов перед другими пользователями: выделить сообщение/объявление/проект, поставить VIP-статус на месяц, получить дополнительные функции: подсказки (для игр) или "усилители" достижения цели на ресурсе.

Логичнее наверное наоборот, надо добавлять ноль если n < 9?
https://codepen.io/anon/pen/bZPNZj

Секрет в decimal-leading-zero htmlbook.ru/css/list-style-type

Если у вас проблема с тем, как делить код на объекты, это означает, что
1. Вы плохо продумали архитектуру проекта, либо вообще плохо представляете что должен делать проект.

2. Мало опыта - в таком случае не парьтесь, просто пишите код как можете. опыт придет с набиванием шишек, когда будете рефакторить код и понимать что наверное надо было вот так изначально разбить, чтобы сейчас было проще.

3. ООП был придуман как выход для написания крупных приложений, которые пишутся большим количеством программистов. В отличие от модульного программирования ООП позволяло не только разбить код на отдельные куски, но еще и сделать эти куски инкапсулированными независимыми "объектами", каждый из которых может поместиться в голову среднестатистического программиста, чтобы упростить процесс разработки.
Это одна из причин, почему ООП достаточно сложно освоить на маленьких проектах.