которые мать его непойми где живут

посмотри по какому пути их flysystem ищет, может че не так настроил с путями

с синком бы тогда была беда

логично ж?)

на всякий случай глянь

ага, посмотрю
пасиб!

remember_token встановлюється тільки раз, при авторизації?

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

Особисто я стараюсь спершу тест написати/модифікувати. Потім вже код

TDD)

Ну типу того.
Так просто з'являється впевненість, шо не почнеш тести підганяти під код

з мого досвіду підхід такий окуповує себе тільки якщо проект розвивається стабільно без різких переходів одного функціоналу в інший

якщо ж іде підхід накидай базовий функціонал і глянемо то TDD лише трата часу оскільки доки концепція узгодиться реалізація як і тести буде багато разів переписуватись

тому при старті проекту я не використовую його, а просто накидую код і після узгодження пишу тести, потім десь місяць 2 поки все динамічно міняється також просто виправляю баги і пишу фічі які знадобились бізнесу та видаляю непотрібні і коли проект стабілізувався берусь за TDD на цьому етапі він уже допомагає формувати тз

з чого я б рекомендував почати це coverage не гнатись за 100% а дивитись що тест заходить куди потрібно + в ігнор добавити папку які не збираєшся тестувати (Exceptions,Providers,Nova) і дивитись куди тест не заходить (наприклад if)

ось наприклад як в мене в одному з проектів виглядає

Прочитал статью. Главное не 100% покрытие, а как минимум уверенность работы фич

проте тут треба бути уважним, якщо код покрити тестами це не означає що він тестується яскравий приклад валідація, ми можемо перевірити тестом успішне проходження але не будемо впевнені що якщо не передамо параметр буде помилка

ага

Вот тоже происходит постоянное изменение возвращаемых данных. Смысл тратится на tdd? Его нет, я не студия, архитектора нет

до речі ще один підхід який я використовую щоб не занадто багато часу на тести тратити
- спочатку прописую в тести лише базовий функціонал (наприклад при створенні успішне створення)
- якщо зявляється баг пишу тест який перевірить що баг виправлений (до чи після коду питання інше)

таким чином перевіряю щоо старі баги не повторюються і одночасно не старають покривати всі варіанти тестами одразу