Кирилл Мокевнин

Если очень узко, то функция `map` в отличие от цикла "отображает" набор, то есть обрабатывает каждый элемент и возвращает новую коллекцию. Именно это нужно делать когда мы работаем с JSX. А циклы это не функции, которые могут возвращать значения, это конструкция языка с помощью которой, например, можно собирать переменные. Из-за того что JSX это декларативная штука (мы описываем ее как есть, а не получаем в результате вычислений), циклы туда просто не встроить.

Циклы это пример императивного программирования, в то время как функции высшего порядка (filter, map, reduce) – декларативного (функциональный подход). Второй подход в js более канонический (ближе к функциональным языкам) и позволяет писать гораздо более понятный и лаконичный код. При условии, конечно, что вы знакомы с этой парадигмой.

Кстати в декларативном коде не используют переменные (если писать правильно), они там просто не нужны. Только константы.

Вот посмотрите код из бекенд проекта в котором нет ни одного цикла: https://github.com/Hexlet/hexlet-exercise-kit/blob...

row = {lk: {id: 181, name: "Client_name"}, lpp: {id: 123, name: "Client_name2" }}
row.map{ |k, v| v[:id] }

Функции высшего порядка всему голова. https://ruby-doc.org/core-2.6.3/Enumerable.html

Когда задают этот вопрос, в первую очередь имеют ввиду режим работы FastCGI. При таком подходе, одного Nginx недостаточно (тут нужно понимать про неблокирующую модель работы nginx). Для этого нужно чтобы само приложение стартовало как часть веб-сервера, написанного на самом PHP (именно загружалось в память один раз, а не на каждый запрос!). Такое реализовано в некоторых проектах, но на PHP не прижилось (пока). А вот во всех остальных языках общего назначения, всегда поднимается сервер самого языка.

p.s. Кто-то может сказать "но ведь fastcgi есть, php уже работает с nginx". На самом деле это эмуляция, реального fastcgi там нет и оно невозможно просто так, php не так то легко загнать в эту модель (внутрь языка вшито слишком много всего, что заточено под одноразовый запуск).

p.s.s Встроенный сервер PHP тоже обманка. Он подходит только для девелопмента и там нет загрузки кода в память. Он также читает код с диска на каждый запрос.

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

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

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

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

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

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

> чтобы было удобнее удобнее ванильного JS, но наименьшего веса.

Современный ванильный дом вполне удобен. Местами он лучше чем jquery. Достаточно подключить https://polyfill.io/v2/docs/ и можно использовать все современные фишечки.

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

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

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

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

В такой ситуации вам не нужна оркестрация. Берете ansible (управления конфигурацией) и деплоите. В докере есть свой супервизор, который поднимет сервис если он упадет.

p.s. здесь можно подсмотреть уже рабочее решение https://github.com/hexlet-basics/hexlet_basics/blo...