Вот есть примитивный класс


Вопрос: как к нему написать unit-тест, куда положить тест, как запустить, протестировать, проверить результат теста?

Если нет Pear - то все сложно. Нужно либо идти на https://pear.php.net/ читать что там написано, поставить pear, подключить к нему phpunit и убедится что все завелось.
Либо поставить node.js, потом composer, потом подключить пакет phpunit/phpunit. Обе дороги непросты, но по одной из них нужно пройти. Операции нетривиальны и надеюсь, что мне их объяснять тут не придется.   

Дальше - нужно завести себе приличный IDE с поддержкой запуска phpunit. Например phpStorm. Там даже автоматизация создания юнит тестов есть. И визуализация тестового покрытия.

Дальше - проще.
Нужно выкинуть из файла строки 14 и 15, ибо нефиг, это класс или что?
Затем в корне проекта завести каталог `tests`. В этом каталоге завести файл testEmpl.php с примерно следующим содержимым



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

Первая функция теста служит для проверки самого механизма запуска. Что у нас юнит тесты таки есть, таки завелись, и мы таки видим тестируемый класс. 

Вторая функция -  отладочный тест. Это основной инструмент при создании приложения с использованием Test Driven Development (TDD). Он должен находится как можно выше по тексту юнит теста. Характерной особенностью его будет воспроизведение "ситуации из жизни". Предназначение его в том, чтоб позволить разработчику встать точкой останова в функцию и отладчиком посмотреть что же там такое происходит. В нормальной жизни, после завершения отладки, такие тесты выкидываются или бережно укрываются комментариями на всякий случай. Их достают из комментариев, когда потоковый тест(или реальная жизнь) обнаруживает ошибку и нужно подставить данные и посмотреть таки в чем дело.

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

И да, сам класс может содержать любые функции, при условии, что они начинаются не на `test`. Те, что начинаются на test будут запускаться PHPUnit по очереди сверху вниз...

P.S. Надеюсь, не сильно упростил и не сильно запутал 

Спасибо, идея и логика в целом понятна, но на этом этапе Pear и phpunit использовать не хочу, я ещё не особо силён в ООП.
Погуглил, нашёл на гитхабе довольно простую на мой взгляд библиотеку: https://github.com/tomkrush/unit на её примере хотелось бы сразу и ООП подтянуть и юнит-тестирование.

Для начала я так понимаю нам надо всего 3 файла:
unit.php
UnitTestSuite.php
UnitTestCase.php

В UnitTestSuite.php всё боле-менее понятно, там приводится сам тест по сути который пробегается по всему массиву случаев case, тестирует каждый и в конце сообщает сколько пройдено, провалено и всего.

В UnitTestCase.php видно что описаны возможные варианты тестирования, что бы вернул правду assertTrue что бы вернул ложь assertFalse но зачем это всё закатано в абстрактный класс, т.к. в остальных двух файлах я что-то не вижу упоминания UnitTestCase, или наследования, расширения этого абстрактного класса...

И самое главное: как использовать эти файлы для минимальной проверки чего-либо? Т.к. в первый файл unit я попробовал добавить строки:

На выходе он мне просто выдал число (сумму времени я так понял) и всё. А где сообщение о наличии, отсутствии ошибок?

Вероятно, нужно спросить у автора. Хотя он забросил проект 5 лет назад. может и послать   
Можно поискать применения класса в php проектах самого автора. 
Вроде bella на нем.

Ок я вас понял. Меня интересует не конкретно эта библиотека, а как правильно написать простейший аналог теста самому? Может быть не из 3, а из 2 или одного файла (тестируемый класс и тест лежат в одном файле).
Т.е. понятно что надо вызывать в цикле класс и передавать туда разные параметры, результат если false фиксировать параметр на котором было false и куда-то логировать этот случай так?

Нужно определить цель. Либо `я хочу сам написать класс тестирования и посмотеть что получится` либо `хочу научится писать юнит тесты и использовать их в дальнейшем`. Во втором случае НУЖНО поставить phpunit. Просто по тому, что все современные проекты для тестирования используют именно его. Это стандарт. Это поддерживается всеми подходящими IDE.
Разумнее всего поставить composer. Composer - еще один инструмент, который фактически становится стандартом. После этого подключить phpunit - одна команда компоузера.

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

composer у меня есть, боюсь что в phpunit не написав ни одного своего класса тестирования разобраться будет сложновато...

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

Пир прошлый век. Композер рулит ) Это для начала.
Ну а тесты - всегда хотел начать их писать, но руки постоянно не доходят 
Как оно вообще - установите например какой нибудь компонент симфонии (главное чтобы вы понимали что он делает) и посмотрите его тесты.
Ну а PHPUnit вообще простой - просто классы с методами с префиксом test в отдаленном представлении.