Сергей Соколов

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

Если говорить про "запросы к БД", то для таких тестов "массив с данными" использовать просто глупо. Это получится какой-то формальный тест: "проверяем, что метод возвращает массив из трех строк - и тут же возвращаем этот самый массив". В чем смысл? Если вы тестируете запрос к БД, то и надо тестировать запрос к БД. По-другому никак.

Здесь я отвлекусь, и порассуждаю на тему того, что на самом деле тестирование - это гораздо более трудоёмкая задача, чем обычно считается. И как следствие, большая часть тестов - это такая вот туфта. Либо тест заранее возвращает нужные данные, либо тестирует один-два кейса. А вариантов неправильных входящих данных ведь может быть огромное количество. То есть по-хорошему на такой заведомо сложный (и принципиально неделимый!) метод нужно десятка два тестов.

И сюда же использование для тестов БД другой системы. Например основная БД MySQL, а для тестов используется Sqlite. Тут сразу можно сказать, что это профанация. Различие даже в какой-то одной настройке БД может повлиять на результаты запроса (и теста как следствие) - а тут и вовсе используется совсем другая БД.

С другой стороны, работу с БД скорее стоит тестировать не в юнит тестах, а скажем в интеграционных. Но не будем углубляться.

Массив же "с данными, симулирующими ответ из базы данных" используется на следующему уровне, там где требуется "ответ из базы данных". Взьмём метод, который использует данные, полученные из БД. Например авторизация юзера. Этот метод должен не сам лезть в базу, а дёргать отдельный метод, вполне возможно, что совсем другого класса. И вот чтобы протестировать авторизацию, вы и мокаете метод для работы с БД, и из этого мока возвращаете тот самый массив без всякого обращения к бд.

Здесь нелишне будет напомнить название доклада с одной из последних конференций по пхп. Дословно не помню, но что-то вроде "Делайте методы как можно короче. Ваши тесты скажут вам спасибо." Собственно, именно при тестировании очень быстро начинаешь понимать удобство атомарных (то есть выполняющих какую-то одну простую операцию) методов. А без тестов пройдёт довольно много времени, пока не понадобится этот длинный метод отрефакторить, и по итогам менять кучу кода, который его вызывает.

Так что разбивайте ваши длинные методы на мелкие, и тогда вопрос, как их тестировать, в большинстве случаев отпадёт сам собой.

RTFM: https://learn.javascript.ru/async-await

1. Нельзя итерироваться по объекту и одновременно изменять его
2. pop удаляет с конца, а for of идет по массиву сначала

Первая итерация цикла number=3, pop удаляет с конца, то есть 5
вторая итерация number=8, pop удаляет 9
и так далее
когда number=6(четвертая итерация), 6 - это последний элемент массива, так как остальные удалил pop

Проксируется в целом ровно точно так же, как и любая сетевая нагрузка: клиенты [n] -> балансер -> сервера [m]. Лимит портов в 65к достаточно просто преодолевается путем добавления дополнительных сетевых адаптеров/каналов.
Дополнительные ссылки:
https://unetworkingab.medium.com/millions-of-activ...
https://blog.postman.com/postman-engineering-milli...
https://serverfault.com/questions/725224/how-to-ha...
https://josephmate.github.io/2022-04-14-max-connec...
https://github.com/eranyanay/1m-go-websockets
https://github.com/ramsicandra/1million-ws

Кроме того, WS коннекты можно балансировать как HTTP - банальным редиректом на прямой коннект к серверу. Т.е. клиент коннектится к балансеру, а он ему говорит: "а теперь тебе вот сюда коннектится надо". Или можно совмещать. Пару слов про проксирование WS в nginx: в сети пишут, что nginx с этим плохо справляется под существенной нагрузкой и лучше всего проксировать WS через специализированные прокси типа HAProxy.

var timeoutId;
// ...
timeoutId = setTimeout(...
// ...
timeoutId = setTimeout(...
// ...
function stop() {
  clearTimeout(timeoutId);
}
document.getElementById("placeholder_text").click = stop;

Ну и не называй функцию do, есть ключевое слово do ... while.

В package.json есть раздел overrides как раз для таких модификаций зависимостей зависимостей. В примерах в документации там почему-то акцент сделан только на версии пакетов, но можно и полностью заменить пакет на свой, если указать не версию, а локальный путь к нему.

const dateTimeFormatter = new Intl.DateTimeFormat(
  'sv-SE',
  {
    dateStyle: 'short',
    timeStyle: 'medium',
  },
);
console.log(dateTimeFormatter.format(new Date()));
// "2024-01-29 09:11:47" 
console.log(dateTimeFormatter.resolvedOptions().timeZone);
// "Europe/Moscow"