Serg

В современных браузерах задача решается нативно через IntersectionObserver, для более старых есть polyfill.

> Насколько я понимаю, смысл mock-функций в jest - это заглушки для функций, чтобы не тащить код всего модуля и не замедлять процесс тестирования.

Это не совсем так. Моки подразумевают, что вы прямо проверяете то что мокаете. Что функция была вызвана, что запрос был выполнен. Это и называется мокинг. А просто заглушка это стаб. Ее смысл не в том чтобы не тащить код, а в том чтобы изолировать побочные эффекты и добиться детерминированности. К последнему, например, относятся таймеры и рандомные числа. Если все это используется внутри программы, то вы не сможете просто так ее протестировать.

Подводя итог, мокают для того чтобы проверить сам мок, например вы хотите убедиться что запрос действительно делался (как в примере документации jest). В остальных случаях у вас стаб (даже если либа называет его моком). Стаб используется для того чтобы тестировать свой код, а стаб нужен только для изоляции побочного эффекта.

Ни первое ни второе напрямую с видом тестирования не связано. Моки и стабы могут применяться практически на любом уровне автоматизированного тестирования.

Темы для самостоятельного изучения:

Побочные эффекты
Детерминированность
Чистые функции
https://martinfowler.com/articles/mocksArentStubs.html

А зачем мучиться ?

Вот есть у вас блок, нужно вам сделать его 200px на 100px.

.block {
    width: 200px;
    height: 100px;
    background-color: skyblue;
}

И тут вам нужны внутренние отступы. Легче ведь просто указать
padding: 20px
Чем пересчитывать все и писать:

width: 180px;
height: 80px;
padding: 20px

можно условно считать, что fetch это низкоуровневая реализация, а axios - более высокоуровневая библиотека. Fetch он вам предоставляет минимум для работы с запросами, в аксиос есть дополнительные интересные плюшки. И вы вероятно правы, - если написать обертку над фетчем (а ее скорее всего придется писать в более или менне непростом сайте), то получится как минимум кастрированный аксиос, как максимум — что-то лучше.

const arr = Object.entries(obj).map(([ k, v ]) => ({ id: +k, name: v.nameEn }));

но у меня такая же обертка создается и работает через call.

Да ну?

Правильно будет так:
f.call('test2', 1, 2);

В чате хекслета slack-ru.hexlet.io около двух тысяч разработчиков

Хороший кандидат на должность 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.

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

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

Эта тема, в первую очередь, связана со знанием операционных систем. Читайте соответствующие книги

Если говорить про конкретные инструменты и их использование, начните с автоматизации деплоя и развертывания инфраструктуры используя инструменты ansible и terraform. Далее переведите локальную разработку на docker-composer. Затем можно будет тащить докер в продакшен (используя в примитивном случае тот же ansible). Про докер можно почитать здесь https://guides.hexlet.io/docker/

coverage говорит о покрытии тестами конкретных строк. Если во время прогона тестов не были затронуты какие-то строки исходного кода, то coverage будет менее 100%. В среднем считается что хорошее покрытие это > 80%. 100% достичь слишком трудно и дорого (и не нужно).

> И если я напишу еще 1000 такого типа тестов это лишь будет гарантировать, что всё хорошо на этих 1000 наборах данных, а вдруг ошибка как раз в другом, 1001-м наборе?

Гарантий вам никто не даст. Для гарантий есть формальная верификация, но это больше про математику чем про программирование. А так это ответственность программиста тестировать пограничные случаи. Ничего страшного в том что вы их пропустили обычно не приосходит. Просто если возникнет баг, то сначала добавите тест который его воспроизведет, а затем уже почините.

Из интересного:

* property-based testing https://en.wikipedia.org/wiki/QuickCheck
* bdd behat.org/en/latest/guides.html
* browser tests https://codeception.com/
* как писать тесты (концептуальная история) https://ru.hexlet.io/blog/posts/how-to-test-code

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Книга которая учит не только синтаксису, но и тому как писать кот грамотно https://github.com/MostlyAdequate/mostly-adequate-...

Конечно можно
Shift + Alt + Down или Shift + Alt + Up

P.S. Файл > Настройки > Сочетания клавиш

Там же можно добавлять свои клавиатурные команды. Для этого нужно нажать на ссылку keybindings.json и разместить свой код в правом окне, затем сохранить файл keybindings.json.

Например, так можно добавить возможность менять регистр символов с помощью клавиш CTRL+SHIFT+U и CTRL+SHIFT+L:

[
 {
    "key": "ctrl+shift+u",
    "command": "editor.action.transformToUppercase",
    "when": "editorTextFocus"
 },
 {
    "key": "ctrl+shift+l",
    "command": "editor.action.transformToLowercase",
    "when": "editorTextFocus"
 }
]