Сергей Протько

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

2)

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

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

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

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

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

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

и нужно ли это делать в юнит-тестах?

не нужно, поскольку вы таким образом жестко привязываете себя к текущей реализации. Чем меньше ваши тесты знают о тестируемом коде - тем лучше. В целом примите за правило что мокать нужно либо интерфейсы (причем ваши желательно, инверсия зависимости и все такое), либо то что общается с внешним миром. Все остальное желательно не мокать что бы не завязывать тесты на имплементацию.

Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.

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

С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

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

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

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

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

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

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

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

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

Как вы тестируете статические методы?

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

В вашем же вопросе вы интересуетесь как мокать статические методы. И тут ответ тоже никак:

Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.

Есть правда еще мокери всякие и т.д.