Alexey Hog

Угу. Сначала понаставим @, чтобы скрыть все ошибки, а потом будем голову ломать, почему ничего не работает и ошибок не показывает.

А вообще, это делается в одну строку.

file_put_contents($outfilename, str_replace('Российский рубль', 'RUB', file_get_contents($infilename)));

$grouped = [];

foreach ($arr as [ 'id' => $id, 'name' => $name, 'key' => $key ]) {
  $grouped[$key][$name] ??= [ 'name' => $name, 'ids' => [] ];
  $grouped[$key][$name]['ids'][] = $id;
}

foreach ($keys as $k) {
  $$k = array_map(fn($n) => [
    'name' => $n['name'],
    'ids' => implode(', ', $n['ids'])
  ], array_values($grouped[$k] ?? []));
}

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

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

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

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

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

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

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

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

Например так



Для любого угла градиента

colors: markerColors, // Устанавливаем цвета маркеров в зависимости от результата

Эта настройка предназначена для назначения цветов не отдельных маркеров, а относящихся к одному набору данных. Так что, чтобы заработало так, как вы хотите, придётся данные разделить. После чего использовать эту настройку станет уже необязательно - цвета можно задавать непосредственно внутри наборов данных. Недостаток - общей линией точки на графике не будут соединены.

Другой вариант - воспользоваться свойством discrete, позволяющим индивидуально настраивать внешний вид каждого маркера. Всплывающую подсказку это никак не затрагивает, так что её придётся кастомизировать отдельно.

Если вы просто откроете настройки шторма и в поиске (слева вверху) просто напишите три буквы "git", то легко найдете настройку "Explicitly check for incoming commits remote", которую следует выставить в Always

Так же можете изменить "Check for conflicts with the server every"

VPN-туннели между площадками и подклюние принтеров на сервере. Лучше, если принтеры сетевые и подключение будет сразу по ip-адресам принтеров. Хуже, если расшаривать доступ к принтерам на ПК, но всё равно худо-бедно будет работать.

const filteredProducts = computed(() => {
  const search = searchQuery.value.toLowerCase();
  return search.length > 2
    ? data.value.filter(n => n.title.toLowerCase().includes(search))
    : null;
});

<ul v-if="filteredProducts" class="search-result">
  <li v-if="!filteredProducts.length">
    <h3>ничего не найдено</h3>
  </li>
  <li v-for="n in filteredProducts">
    <div>
      <Image :src="n.image" :alt="n.title" width="40" height="40" />
    </div>
    <h3>{{ n.title }}</h3>
    <div>
      <p>{{ n.price }}</p>
    </div>
  </li>
</ul>

Показываем не более одного - добавляем в компонент свойство, которое будет содержать id, индекс или ещё что-то уникальное для каждого из элементов данных (да хоть бы и ссылку на сам элемент). Показываем скрытое в зависимости от равенства значения этого свойства тому, что доступно в текущей итерации v-for.

Или, показываем несколько сразу - создаём отдельный компонент, в экземпляры которого будут передаваться элементы данных. Внутри компонента свойство, в зависимости от значения которого (истина-ложь) показываем или скрываем чего там надо.

Как получить строки таблицы:

// если гарантируется отсутствие thead и tfoot, или их содержимое также должно учитываться
const { rows } = table;

// если tbody один
const [ { rows } ] = table.tBodies;

// если tbody несколько
const rows = Array.prototype.flatMap.call(table.tBodies, n => [...n.rows]);
// или
const rows = [].concat(...Array.from(table.tBodies, n => [...n.children]));
// или
const rows = table.querySelectorAll('tbody tr');

Как получить средний элемент:

const middle = arr => arr[arr.length >> 1];
// или
const middle = arr => arr[Math.floor(arr.length / 2)];
// или
const middle = arr => arr[Math.round(~-arr.length / 2)];
// или
const middle = arr => arr[(arr.length - arr.length % 2) / 2];

Всё, можно доставать ячейку:

const cell = middle(middle(rows).cells);
// или
const cell = middle([].reduce.call(rows, (acc, n) => (acc.push(...n.children), acc), []));
// или, без получения строк
const cell = middle(table.querySelectorAll('tbody td'));

Строки сложить в массив. Завести два индекса - текущей строки и её последнего отображаемого символа. Если при увеличении количества отображаемых символов выходим за границу строки - переключаемся на следующую строку и сбрасываем счётчик символов.

Куда, что и с какой задержкой будем печатать:

const el = document.querySelector('p');
const strings = [ 'hello, world!!', 'fuck the world', 'fuck everything' ];
const delay = 100;

Печатаем:

function Typewriter(el, strings, delay) {
  let i = 0;
  let length = 0;

  return setInterval(() => {
    if (++length > strings[i].length) {
      i = -~i % strings.length;
      length = 0;
    }

    el.textContent = strings[i].slice(0, length);
  }, delay);
}


const intervalId = Typewriter(el, strings, delay);
// хотим остановить, делаем так: clearInterval(intervalId);

или

function Typewriter(el, strings, delay) {
  let timeoutId = null;

  (function step(i, length) {
    length = -~length % -~strings[i].length;
    i = (i + !length) % strings.length;
    el.innerText = strings[i].substring(0, length);
    timeoutId = setTimeout(step, delay, i, length);
  })(0, 0);

  return () => clearTimeout(timeoutId);
}


const stop = Typewriter(el, strings, delay);
// хотим остановить, делаем так: stop();

Вы берёте childNodes, куда входят не только элементы, но и текстовые узлы между элементами (переводы строк).

// [object NodeList] (7)
[#text,<div/>,#text,<div/>,#text,<div/>,#text]

Так вот у этих текстовых узлов нет параметра offsetWidth, соответственно вы складываете undefined, получая NaN.

- let box = document.querySelector(".box").childNodes;
+ let box = document.querySelector(".box").children;
- box.forEach((item) => {
+ for (let item of box) {
- })
+ }