Негативні тести та чому з ними важко

Вимоги: З брокеру забираємо об’єкт та записуємо в БД. В об’єкті чотири атрибути(id1,id2,id3,id4) - цілі числа від 1 до 10 включно. Якщо хоч один атрибут некоректний - запис в БД не робимо.

Як бачимо на тестування позитивних кейсів необхідно 2-3 тести (навіть якщо атрибутів буде більше). А на негативне тестування всього одного поля +-7(більше).

До того ж останній кейс показує, що при помилці (забули прибрати негативні дані id1 та додали негативні до id2) отримаємо такий самий результат(немає запису в БД) але не через поле id2 а через нашу помилку(копіпаст id1 ).

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

А тепер уявімо що атрибутів 100+.

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

Негативні кейси потрібні (хоча б перевірити, що консьюмер не відпаде після невдалого вичитування об'єкту), але в міру (щоб потім не виявилось, що вони перевіряють нічого та їх важко підтримувати).