Выкарыстоўвайце тэсты як доказы

Пачніце з патрабавання

Тэсты даюць доказы для канкрэтных сцверджанняў. Паспяховы запуск тэстаў не пацвярджае ўсе ўласцівасці праграмы. Перад запытам тэстаў вызначце істотныя паводзіны і дэфект, які павінна выявіць кожная праверка.

Для выдуманага сцэнарыя экспарту даных арганізацыі галоўнае патрабаванне — ізаляцыя даных. Карыстальнік арганізацыі A не павінен атрымліваць запісы арганізацыі B. Тэст, які правярае толькі паспяховае спампоўванне, не пацвярджае гэтае патрабаванне.

Папрасіце агента растлумачыць сувязь паміж патрабаваннем і праверачным сцверджаннем. Гэта палягчае выяўленне адсутных выпадкаў да таго, як набор тэстаў стане вялікім.

Выберыце адпаведны абсяг тэсту

Модульны тэст можа хутка праверыць невялікае пераўтварэнне. Інтэграцыйны тэст можа праверыць сумесную працу кампанентаў. End-to-end тэст можа праверыць істотную паслядоўнасць дзеянняў карыстальніка ў разгорнутай праграме або яе рэпрэзентатыўным варыянце.

Выкарыстоўвайце найвузейшы абсяг, які дае неабходныя доказы. Сродку фарматавання не патрэбны поўны браўзерны тэст для кожнага ўваходнага значэння. Мяжа аўтарызацыі можа патрабаваць рэальнага маршруту і шляху доступу да даных. Крытычнае ўзаемадзеянне ў браўзеры патрабуе доказаў пра адлюстраваны інтэрфейс.

Няма фіксаваных суадносін тыпаў тэстаў, якія падыходзяць кожнай сістэме. Выбірайце паводле збою, які трэба выявіць, і кошту суправаджэння праверкі.

Пазбягайце агульнага памылковага дапушчэння

Агент можа напісаць рэалізацыю і тэсты на аснове аднаго і таго ж няправільнага разумення. Яны могуць супадаць, а патрабаванне застанецца нявыкананым.

Дапусцім, рэалізацыя фільтруе запісы паводле ID арганізацыі, перададзенага ў запыце. Тэст выкарыстоўвае адзін і той жа ID для карыстальніка, які ўвайшоў у сістэму, і для запыту. Ён праходзіць. Адсутны выпадак — карыстальнік, які запытвае ID іншай арганізацыі.

Дадайце гэты выпадак праз сапраўдны шлях даверанай ідэнтычнасці і аўтарызацыі. Заглушка, якая заўсёды вяртае «дазволена», не можа пацвердзіць ізаляцыю арандатараў. Яна пацвярджае толькі паводзіны пасля паспяховай аўтарызацыі.

Праверце, што тэст можа не прайсці

Для вядомага дэфекту запусціце новы рэгрэсійны тэст на дэфектнай версіі ў ізаляванай галіне. Пацвердзіце, што ён не праходзіць з патрэбнай прычыны. Затым ужывіце выпраўленне і запусціце яго зноў.

Тэст, які не праходзіць праз немагчымасць загрузіць тэставыя даныя, яшчэ не дае доказаў пра бізнес-паводзіны. Вывучыце збой, а не толькі код завяршэння.

Для шырэйшых змен мутацыйнае тэставанне можа дапамагчы ацаніць, ці выклікаюць выбраныя змены кода няўдачы тэстаў. Яно мае кошт і не замяняе праверку патрабаванняў. Выкарыстоўвайце яго там, дзе дадатковыя доказы падтрымліваюць рашэнне з істотнымі наступствамі.

Звязвайце доказы са зменай

Запускайце адпаведныя праверкі на канчатковай рэвізіі. Запісвайце прапушчаныя праверкі і прычыны. Вынік ранейшага commit можа ўжо не дзейнічаць пасля выпраўлення паводле заўвагі рэцэнзента.

Захоўвайце тэсты зразумелымі. Аддавайце перавагу яўнай падрыхтоўцы і праверачнаму сцверджанню перад вялікай дапаможнай функцыяй, якая хавае істотную ўмову. Прыбірайце залішнія праверкі, калі яны павялічваюць кошт суправаджэння, не выяўляючы іншага збою.

Рэцэнзент павінен умець сказаць, што пацвярджаюць тэсты і што застаецца нявызначаным. Такое тлумачэнне карыснейшае за вялікую колькасць тэстаў.