Anton Mashletov

const obj = Object.assign({}, ...arr.map((n, i) => ({ [n]: arr2[i] })));
// или
const obj = arr.reduce((acc, n, i) => ({ ...acc, [n]: arr2[i] }), {});

или, в более общем виде:

const combine = (keys, values) =>
  keys.reduce((acc, n, i) => (acc[n] = values[i], acc), {});


const obj = combine(arr, arr2);

точка с запятой после
Person.prototype.saySomething = function(word){
console.log("Hello, my name is "+this.firstName+" "+this.lastName+" and i say : "+word);
}

interface Window {
  someVariable: Number;
}

window.someVariable = 1;

Протокол HTTP не поддерживает отдачу нескольких файлов в ответ на один запрос. Вам нужно либо отдавать один архив, либо инициировать со стороны клиента несколько запросов.

Тесты очень удобно например на этапе написания логики. Есть упражнения по PHP exercism.io. Там можно прощупать силу и пользу PHPUNIT.

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

* Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
- Время.
- Протухание по бизнес логике.
Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
- При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

overflow-y: scroll;
overflow-x: hidden;
overflow-y: -moz-scrollbars-none;
overflow-style: none;

&::-webkit-scrollbar {
    width: 0;
}

1) это не юнит тест, это интеграционный тест. Он проверят "часть системы в сборе", в вашем случае апишку. Если бы вы тестировали через UI (то есть через ангуляр) - это называлось бы end-to-end тест (от кнопок до базы данных мол).

2)

На просторах инета вижу простые примеры тестов которые проверяют на true false

Давайте думать. Вот как бы вы проверяли такое руками? Можете придумать? А теперь можете написать скрипт который проверяет это за вас? Вот вы и умеете писать интеграционные тесты, это не очень сложно. Нужно только не зацикливаться.

Что вам по сути важно когда вы пишите апишку? Скорее всего вы хотите всегда знать что структура ваших ответов не сломалась. Что вы случайно не поменяли имя поля, или случайно не убрали нужные поля. Для этого есть такая штука как json schema. То есть мы берем json и проверяем на соответствие. Опять же для phpunit можно найти готовые ассерты что бы не пилить велосипед.

Далее, что еще нам может хотеться проверить - статус коды. Это опять же легко и думаю в документации к laravel это есть. Так же возможно вы захотите проверять заголовки но это уже специфичные штуки.

Словом все что вы хотите проверить - вы просто проверяете. Правильно - это когда оно выполняет ваши потребности.

Ну и возможно вам захочется проверить данные в json ответе. Тут уже есть кучи вариантов. Я например запилил свой велосипед для частичного сравнения JSON-а (ну не интересно мне все проверять). Можно и другими решениями это делать, но лично я такие штуки на этом уровне проверяю крайне редко, ибо... ну у меня другие тесты за проверку логики отвечают.

Мне очень помогло вот это видео - https://www.youtube.com/watch?v=8u6_hctdhqI Хотя, стоит заметить, что до него я потратил десятки часов на чтение статей ;)

Хорошей практикой считается создавать suite под разные виды тестов: unit, интеграционные (функциональные), UI
Все они служат для повышение качества софта.

Но unit в первую очередь нужны разработчикам для уверенности при рефакторинге и лучшего понимания чужого кода, конечно, если они написаны не только ради того чтобы было. Они должны быть очень быстрыми и тестировать отдельные участки кода. Для этого при написании таких тестов часто используют моки.

То что вы описали $this->visit('/users') / see / dontSee / press. ближе всего к UI тестам. Это проверка софта с точки зрения пользователя. Очень часто они написаны даже не разработчиком, а QA. Если для их выполнения настроить Selenium, то можно приятно удивить клиента :)

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

Юнит-тестирование предназначено для тестирования конкретного метода или класса.
В вашем случае это будут тесты для модели, например проверка, что модель создает запись в базе с определенной структурой.

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

Функциональное тестирование проверяет соотвествие требованиям проекта. Например, при нажатии кнопки Удалить появляется окно подтверждение с текстом "Вы уверены", затем при нажатии кнопки "Да", запись удаляется из БД и пользователю выводится сообщение "Запись успешно удалена!".

Тест на регрессию - это повторная проверка работы конкретного участка кода. Как правило это участок кода, который не был покрыт тестами ранее.

PHPUnit изначально предназначен для юнит-тестирования, однако это не мешает вам использовать его для других видов тестирования. Есть даже коннекторы к WebDriver.

Тестирование контроллеров и моделей по отдельности - это юнит-тесты.
Тестирование связки контроллер-модель - это интеграционное тестирование.
Тестрование работы сайта целиком с помощью того же Selenium и т.п. - это функциональное тестирование.

$set = [1, 2, 3]; // комплект
$items = [1, 2, 3, 4, 5]; // выбранные товары
$diff = array_diff($set, $items);
if (0 == count($diff)) {
  // дать скидку на товары в $set
}

Потому что приведение типов, и нестрогое сравнение.

А вот строгое:
console.log(false === 0) // → false

Вот вам табличка, что к чему приводится

https://dorey.github.io/JavaScript-Equality-Table/