Олег

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

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

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

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

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

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

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

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

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

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

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

В связи с этим вопрос – что ещё нужно знать?

Бэкенд вам в любом случае нужен.

Если я правильно понимаю, Angular, Vue и прочие фреймворки – это только фронтенд.

Все верно.

Куда не сунься, везде о веб-разработке говорится, как о разработке именно фронтенда, а также это непременно связано с Node.js (дабы что-то написать на ангуляре, без него никак). Каким боком связан фронтенд с Node.js - я не понимаю, т.к. Node.js - это, по сути, способ запустить JS вне браузера.

Скорее всего вы читаете статьи о фронтенде, потому в них о бэкенде ничего и нет. Как вы знаете фронтенд пишется на JS и многих подкупает то, что можно поднять NodeJS на бэкенде и используя один язык создавать сайты.

Если я хочу запустить приложение в браузере, то зачем мне node? Это всё меня вводит в ступор, я вижу лишь противоречия.

Вы не путайте. Есть технологии, которые используются в процессе работы приложения и есть технологии, которые используются в процессе разработки приложения. Все эти Gulp, Grunt, Babel, Webpack и прочие - это инструменты разработки. Они ускоряют, упрощают, повышают качество работы. В то время jQuery, Angular, React - это библиотеки и фреймворки, с помощью которых приложение будет работать.

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

Здесь я лишь могу предположить, что сервер вместо html должен обмениваться данными с приложением посредством json или чего-то ещё.

Да, JSON, как самый распространенный. Вам нужен фреймворк для бэкенда, на котором можно развернуть REST API. Насколько мне известно большинство современных фреймворов современных языков программирования, которые используются для веб-разработки, это умеют. Я не могу утверждать точно, я работаю в рамках одного языка.

Всё-таки сервер - это основа любого сетевого приложения, и в первую очередь нужно разработать серверную часть.

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

Вся прелесть SPA в разделении этих частей. Любая из них может быть заменена на другую без особых последствий. Один бэкенд может обслуживать сайты, мобильные приложения, предоставлять доступ к данным для сторонних партнерских приложений, и все это через единый API.

Что ещё нужно изучить? Или перечисленных знаний достаточно?

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

Можно ли не использовать Node.js и, соответственно, npm, если JS (TS) требуется только в браузере? При этом тестирование тоже необходимо.

Да, вполне. На стороне клиента, к примеру, JS+Angular. А на стороне бэкенда, к примеру, PHP+Laravel. Сейчас очень много языков и еще больше фреймворков под них. Выбирайте то, что для вас проще.

fail2ban если сконфигурируете корректно - подойдет. Он анализирует логи (в вашем случае access.log), выявляет подозрительные элементы на основе регулярных выражений и выполняет указанное вами действие.

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

Возможно есть более простые решения (например, через htaccess).

www.restapitutorial.com

Правильно писать так, как в примере от Laravel (файл Example.vue).

Хотя, можно обойтись и без Example.vue, а писать бизнес логику в app.js.
Например, вот этот товарищ так и делает:
https://www.youtube.com/watch?v=ZEF3TAAzfVM

Но, первый вариант, более правильный.
Когда начнешь так писать, возникнет необходимость в обмене данными между разными vues.
Для этого используй Vuex.
Можешь посмотреть о нем вот здесь:
https://www.youtube.com/playlist?list=PL55RiY5tL51...

А в остальном, в правильном направлении движешься.
Приложения с использованием связки Laravel+Vue.js получаются реально классными.

Желаю удачи!