Где можно посмотреть практики написания хороших тестов для laravel?
В общем можно посмотреть у  Jeffrey Way на https://laracasts.com
Еще мне нравилась его книга правда наверное она не много устарела.

Начал копаться и вот здесь не понимаю каким образом в шаблон эндпоинта подставляется конкретный id. https://github.com/austintoddj/canvas/blob/master/...к
Покопался и открыл для себя тоже кое что новое..
В ссылке есть ниже метод и у него сверху мета тэг @dataProvider
Что это такое почитать об этом можно здесь

Что касательно true way or laravel way - это все относительно.
Например в этом проекте от тестирует отношения в моделях, это скажем прям такое..
Потом он тестирует консольные команды..интересно зачем?
Конечно можно все протестировать, но какой в этом собственно смысл?
Организация папок - это тоже дело щепетильное, как и название методов и переменных.

Мне больше нравиться подход DDD. Как правило в проекте чаще всего меняются бизнес требования а не инфраструктура.
Что может произойти вероятнее - поменять базу данных или поменять алгоритм начисление денежных средств?
Так вот тестирование доменной области намного оправдание чем тестирование отношений модели в Eloquent.
Ладно, что - то я разошелся, короче говоря, пишите тесты -> набирайтесь опыта -> рефакторинг -> пишите тесты.
В программировании можно какие угодно "бест практики" выдумывать в бесконечных вариациях. Я бы не смотрел на эти изобретения. В доках все понятно написано. Http тесты тестируют http запросы и больше ничего, список ассертов приведен и тд. Тесты не пишут для бест практик и "покрытия", их пишут, чтобы они тебе были нужны как разработчику, фиксировали нужный функционал и работали. А не тесты ради тестов. По структуре все просто - одинаковые объекты, конфиги и тд (как, например у него здесь везде дублируется primaryPost) - в setUp тест класса если во всех тестах или выносится в TestCase/трейты и дальше тесты. Каждый запускается с нуля, за редким исключением прописываются зависимости через @depends. И тесты нужно писать до разработки(тдд). Иначе это будет фигня, а не тесты. Или скорее всего не будут т.к. "покрывать" существующий функционал это очень утомительно и неинтересно. В отличие от тдд, с которым разработка легка и приятна.