Виктор Кожухарь

Вам не надо тестировать приватные методы.
Но как же тогда быть, вы скажете?
Публичные методы используют эти приватные методы, так и проходит тестирование.
Из этого вытекает, что класс должен быть небольшим и выполнять только одну задачу. Поэтому его приватные методы будут всегда задействованы при тестировании публичных.
Но вы скажете, что у вас там в публичных методах обращения к базе данных и внешним API, как же тут быть?
А быть тут просто: все зависимости вашего класса должны включаться в качестве аргументов конструктора, и через использование интерфейсов в аргументах. (Dependency Injection)
Таким образом в тесте все зависимости класса заменяются теми же моками, и вы легко тестируете не просто сферического корня в вакууме (приватный метод), а именно то, что и нужно тестировать: функциональность самого класса, а не его частей, потому что в OOP именно класс является как бы атомом функционала.
Но... если вам всё же таки очень надо, то можно это сделать при помощи рефлексии:
Хорошей практикой является использовать всегда protected вместо private.
Пишете себе такую вот утилиту:

class PHPUnitUtil
{
  public static function callMethod($obj, $name, array $args) {
        $class = new \ReflectionClass($obj);
        $method = $class->getMethod($name);
        // $method->setAccessible(true); // если PHP старше 8.1.0
        return $method->invokeArgs($obj, $args);
    }
}

И используете ее в тестах

$returnVal = PHPUnitUtil::callMethod(
                $this->object,
                '_nameOfProtectedMethod', 
                array($arg1, $arg2)
             );

Есть ещё вариант.

// Оригинальный класс
class Foo {
  protected function stuff() {
    // secret stuff, you want to test
  }
}

// Класс для тестов
class SubFoo extends Foo {
  public function exposedStuff() {
    return $this->stuff();
  }
}

Есть банальные расширения для браузера
https://chromewebstore.google.com/detail/save-page...
https://chromewebstore.google.com/detail/webscrapb...

А так же целое десктопное приложение и ещё одно расширение для браузера
https://github.com/webrecorder/webrecorder-desktop
https://chromewebstore.google.com/detail/webrecord...

1. Вебсокеты - это сложновато.
2. Вебсокеты на PHP - вдвойне сложно. Проблема в том, что PHP задуман как скриптовый язык, т.е. скрипт выполняется заканчивает свою работу. А вебсокет - это постоянное соединение, т.е нам надо, чтобы программа постоянно крутилась в фоне. Вебсокеты можно реализовать на PHP, но, как персонально мне кажется, проще будет выучить Go )) , или же, как в ответе уважаемого Артём , сделать сервер на ноде.
3. Если ваш чат не такой супер-функциональный, как чат в мессенджерах, то вместо вебсокетов можно обойтись SSE (Server Sent Events). SSE так же требует постоянного соединения, но всё работает через HTTP, и это ну прямо намного проще. Единственный недостаток - это то, что SSE работает только в одну сторону: от сервера в браузер. Т.е. запросы из браузера можно получать обычным POST запросом, а отдавать обратно информацию уже через SSE.

С SSE есть два пути:
1. Написать сервер самому, используя какую-то простую библиотеку вроде этой https://github.com/hhxsv5/php-sse
2. Но я бы сделал ещё проще. Есть такой великолепный проект под названием Mercure https://mercure.rocks
Это отдельный сервис на Go, задача которого как раз поддерживать SSE соединение и отправлять сообщения в браузеры. Сервис сидит в фоне, а браузеры подписываются на события через EventSource буквально в три строчки, как описано тут https://mercure.rocks/docs/getting-started
Прелесть этого в том, что для того, чтобы отправить сообщение всем браузерам из кода на PHP, вам надо просто сделать обычный POST запрос на специальный адрес этого сервиса Mercure с телом самого сообщения и его id. Т.е. вам не надо делать никаких долгоживущих процессов на PHP, всё будет работать как раньше.

Т.е. подытожим:
- Браузеры пользователей подписываются на события в Mercure
- Пользователь 1 отправляет текстовое сообщение обычным POST запросом на обычный PHP сайт.
- PHP сайт получает этот POST запрос, определяет, что его надо отправить Пользователю 2, и отправляет соответствующее сообщение обычным POST запросом в сервис Mercure
- Mercure отправляет сообщение Пользователю 2 через SSE, на которые он подписан.
- Сообщение появляется у него на страничке

Выскажу свою личную точку зрения:
1. Изучаем, каким будет трафик сервиса на старте. Если это замена уже работающему высоконагруженному сервису, либо вы на 200% уверены, что нагрузка прямо сразу будет высокой и дальше на 200% точно уверены, что нагрузка будет расти, не выбирайте ни ноду ни Java. Берите, например, Go. Он гораздо быстрее ноды, там даже стандартная библиотека уже имеет готовые решения для всего нужного REST, и есть куча прекрасных сторонних библиотек и фреймворков.
2. А вот если ваш проект новый, вы не знаете, сколько у вас будет пользователей, какая будет нагрузка, то не надо даже думать: берите то решение, которым вы владеете, и с помощью которого вы сможете быстро и дёшево собрать первую версию. Если это даже PHP, то пусть он и будет. С огромной вероятностью ваш сервис будет всё равно переделан и переписан позже, поэтому, чем меньше вы потратите времени и денег в самом начале, тем быстрее выйдете на рынок, и тем больше сэкономите первоначальных инвестиций. А когда проект начнёт приносить прибыль, вот тогда при помощи уже этой прибыли будете решать проблемы производительности

Вот идея кастомного чекбокса на CSS без всякого JS.
https://codepen.io/vitiok78/pen/pmbyzE