Коли ви будуєте сторінку контролю/аналітики або CRUD-модуль у живому проєкті, вам не потрібні “сотні тестів”. Вам потрібні 5–8 тестів, які закривають три головні ризики: витік даних через доступи, неправильна вибірка через фільтри, і “сміття в базі” через валідацію. Це той мінімум, який реально окупається: він ловить помилки відразу, не даючи їм доїхати в прод.
Нижче — логіка, як саме зібрати ці 5–8 тестів. Вони мають бути feature-тестами, бо саме feature перевіряє реальну поведінку маршруту: middleware, policy, контролер, запит, пагінація і FormRequest працюють разом. Unit-тести policy — опційні, але у вашій ситуації (де permissions критичні) головний ефект дають саме HTTP-тести.
Почніть із ролей/акторів. Мінімум два: користувач з правом (редактор/адмін) і користувач без прав (або інша роль). Плюс інколи потрібен “автор” для кейсу “бачить тільки своє”. Далі ви створюєте тестові записи так, щоб фільтри точно могли відсіювати: різні дати, різні статуси, різні автори. Тести мають бути детермінованими: якщо ви створили 3 записи, то ви чітко знаєте, які мають потрапити в результат.
Ось “золотий” набір із 7 тестів, який закриває майже всі регресії для сторінки контролю/CRUD.
Тест 1. Доступ до сторінки контролю: без прав — 403/redirect, з правом — 200.
Це ловить ситуації, коли хтось забув middleware permissions або навпаки — випадково відкрив модуль.
Тест 2. Обмеження видимості: користувач з обмеженою роллю не бачить чужі записи в index.
Це ключовий антивитік. Він повинен падати, якщо хтось прибрав базовий visibleTo($user) або переписав запит “в лоб”.
Тест 3. Фільтр по статусу працює і не розширює доступ.
Ви створюєте записи зі статусами A/B, робите GET /control?status=A і перевіряєте, що в відповіді тільки A. Потім важлива частина: якщо користувач обмежений, він не повинен отримати чужі A — тобто фільтр звужує, але не розширює.
Тест 4. Фільтр по даті: BETWEEN включає межі дня коректно.
Це ловить найчастішу помилку “від/до не включило записи на кінці дня”. Ви робите записи на різних датах/часах, фільтруєте по даті і перевіряєте, що саме потрібні потрапили.
Тест 5. Фільтр по user_id: працює для ролі, якій це дозволено, і ігнорується/не дає витоку для ролі, якій не дозволено.
Наприклад, адміну дозволено дивитись по будь-кому, автору — ні. Тест гарантує, що параметр user_id не став “діркою”.
Тест 6. Пагінація: зберігає query string.
Це UX-регресія, яка в реальності дуже болюча: натискаєш “сторінка 2” і фільтри злітають. Тест простий: викликаєте сторінку з фільтрами і перевіряєте, що лінки пагінації містять ці параметри.
Тест 7. Валідація store/update: невалідні дані не записуються і повертають помилку (422 або redirect з errors).
Це базовий захист. Якщо хтось зняв FormRequest або “спростив” правила, тест падає. Плюс ви перевіряєте, що база не змінилась.
Якщо вам потрібно 8 тестів — додайте ще один “підміна забороненого поля”.
Тест 8. Update з підсунутим полем (наприклад, status/approval_status) не змінює це поле для ролі без права.
Це дуже потужний тест проти ескалації прав через request payload.
Далі — як ці тести мають виглядати технічно, без прив’язки до вашої конкретної таблиці. Ви завжди робите actingAs($user) і відправляєте HTTP запити. Ви перевіряєте статус-код і (важливо) перевіряєте контент відповіді або наявність записів у БД. Для index-сторінки зручніше перевіряти контент (назви/ID) у HTML, а для create/update — assertDatabaseHas / assertDatabaseMissing.
Статуси. 200 — можна дивитись. 302 — успішний store/update з редиректом. 403 — заборонено. 404 — якщо ви ховаєте існування запису і дістаєте його через доступний scope. 422 — для API або для JSON-очікування, або redirect з errors для web-форм. Важливо вибрати консистентну політику і тестувати саме її.
Найчастіша помилка при написанні такого набору — “вимкнути middleware” або “підмінити авторизацію”, щоб тести проходили. Це самообман. Вам потрібні тести, які імітують прод: з permissions, з policies, з реальними маршрутами. Інакше вони не ловлять регресії, заради яких ви їх писали.
Щоб тести були підтримувані, вам потрібні два хелпери. Перший — створення користувачів з ролями/правами (адмін/редактор/автор). Другий — фабрика тестових записів з різними статусами, датами і власниками. Якщо фабрик немає, можна створювати записи руками, але краще винести це в методи в тесті, щоб не було копіпасту.
Висновок: “5–8 тестів” — це не випадкове число. Це мінімальний набір, який закриває реальні ризики: доступи (не показати зайве і не дати виконати дію), фільтри (дата/статус/юзер працюють коректно і не розширюють доступ), пагінація (не губить параметри), і валідація (не пускає сміття). Якщо ці тести є, ви можете додавати нові фільтри і розширення без страху, що тихо зламаєте старі обмеження або відкриєте дані.
