Перевірка гарантій після відмови

Перевірка гарантії після відмови

Для функції, яка додає елемент до двох векторів, запишіть інваріант:розміри однакові й позиції описують той самий запис. Після успіху обидва розміри збільшилися на один. Після відмови за строгої гарантії обидва вектори повинні повністю збігатися з початковими.

Перевірка лише розміру недостатня: старе значення могло змінитися без зміни кількості елементів. Збережіть копії до виклику і порівняйте вміст після перехоплення. Для навчального досліду можна контрольовано кинути виняток між етапами підготовки, щоб перевірити кожний шлях. Це слід відрізняти від реального збою алокатора, який не потрібно видавати за виміряний, якщо його не відтворювали.

RAII гарантує прибирання тимчасових ресурсів при розкручуванні стека, але не відкочує автоматично довільний зовнішній ефект. Уже надрукований рядок, відправлене повідомлення або змінений сторонній файл не зникає лише через виняток. Для таких операцій потрібен окремий протокол транзакції або відновлення.

Ланцюжок expected без прихованого успіху

Для дати parse перевіряє форму, validate – календарні обмеження, а transform може створити текст для виведення. Якщо parse повернув помилку, validate не повинен викликатися. Це можна перевірити лічильником викликів у тестовій версії, не змінюючи робочий результат.

Or_else доречний, коли є осмислена альтернатива:наприклад, прочитати резервний формат або додати контекст до помилки. Підстановка довільної дати сьогодні після будь-якої помилки приховала б некоректний вхід. Відновлення повинне бути частиною вимог, а не способом прибрати червоне повідомлення.

Value_or також потребує обережності. Для необов’язкового параметра масштабування типове 1 може бути правильним. Для суми переказу типове 0 після невдалого розбору може перетворити помилку на іншу операцію. У фінальному звіті потрібно розрізняти «користувач ввів 0» і «значення не прочитано».

Матриця тестів для парсера

Для дати перелік тестів має покривати окремі причини відмови, а не лише кілька випадкових рядків. Синтаксис і календарна правильність незалежні: рядок може мати правильні десять символів, але неіснуючий день. Навпаки, людина може зрозуміти дату зі скісними рисками, але програма з чітким форматом повинна її відхилити як інший протокол.

Таблиця 6.1. Незалежні класи тестових даних

Вхід	Очікування	Що перевіряємо
2024-02-29	успіх	Кратність 4 і високосний лютий.
1900-02-29	range	Століття без кратності 400 не високосне.
2000-02-29	успіх	Виняток для кратності 400.
2024-04-31	range	Місяць із 30 днями.
2024-00-10	range	Межа місяця перевіряється до індексації.
2024-12-00	range	День 0 недопустимий.
2024-2-03	syntax	Фіксована ширина компонента.
2024-02-03x	syntax	Зайвий суфікс не ігнорується.

Після проходження цих тестів можна додати властивісну перевірку: для кожної допустимої дати сформувати канонічний текст, розібрати його і порівняти поля. Така перевірка охоплює багато комбінацій, але не замінює явні неправильні рядки. Вона також має використовувати незалежний спосіб отримання очікуваної дати, інакше однакова помилка у форматуванні й розборі може приховатися.

Для expected важливо перевірити не лише текст повідомлення, а саму категорію. Тест на Error::syntax залишається стабільним, коли пояснення перекладають українською. Окремий тест інтерфейсу перевіряє, що категорія коректно пояснена людині.

Так само для винятків корисно перевірити тип, стан після відмови та код завершення верхнього рівня. Одне повідомлення what() не доводить, що дані не змінилися. Якщо операція повинна мати строгу гарантію, порівняння початкового й кінцевого стану є частиною обов’язкового тесту.