И как да се включи тестовото покритие в разработката

Взаимоотношенията могат да бъдат трудни, без съмнение, но и в много отношения схематични. Могат да се наблюдават модели и да се дефинират фрази.

Един особен модел, който наблюдавах във взаимоотношенията между екипите за разработка и покритието на кода.

Първо, има фазата на невежество, при която разработчиците напълно пренебрегват показателя за покритие на кода, колкото и тестове да пишат.

След това, след като показателят бъде открит, разработчиците са склонни да го обсебват, като го третират като единствения определящ фактор за качеството на тестовия пакет - това е фазата на обсебване.

В крайна сметка връзката ще се развие в крайната фаза, където покритието на кода е един от многото показатели за осигуряване на качеството на софтуера, третиран с необходимото внимание.

Разработчиците, които пишат автоматизирани тестове, са индустриален стандарт, изискването за създаване на софтуер е поддържаем и мащабируем начин.

Всеки пише тестове в днешно време, но почти не толкова много включват покритие на тестове в работните си процеси. Ако попадате в тази категория, нека ви разкажа за покритието.

В компютърните науки тестовото покритие е процентна мярка за степента, до която изходният код на дадена програма се изпълнява, когато се изпълнява конкретен тестов пакет.

Например 50% означава, че половината от нашия код се изпълнява поне веднъж по време на изпълнението на тестовия пакет, а другата половина е напълно пропусната.

100% означава, че изходният код е напълно покрит с тестове. Това не гарантира код без грешки, но ако е направен правилно, ви приближава доста, като същевременно не е огромна тежест за процесите на разработка и поддръжка.

Ето как да включите тестовото покритие в разработката:

  • Когато пишете нов код, използвайте IDE с дебъгера, за да проверите кои редове от новия изходен код са засегнати от тестовете и кои не. Ще се изненадате.
  • Направете измерването на покритие част от CI/CD тръбопровода. Заявките за изтегляне показват как влияят върху цялостното покритие (увеличаване/намаляване/неутрално). Освен това поставете значка за покритие в горната част на файла readme на репото.

Естествената следваща стъпка от „връзката“ изглежда е фазата на обсебване, където разработчиците са склонни да предпочитат тестовото покритие пред всеки друг показател.

Те пишат само тестове на високо ниво (защото идват с най-евтиното покритие) и цялата им увереност произтича от тази единствена статистика.

За съжаление, това често не е достатъчно, защото до края на деня крайната статистика е колко бъгове сме позволили да се промъкнат до крайния потребител. Когато сте във фазата на обсебване, най-вероятно няма да откриете, че тези два показателя корелират според очакванията.

Ето как да изведете осигуряването на качеството на вашия софтуер на следващото ниво:

  • Внимавайте за логическата страна на вашите тестове, а не само за обхванатите редове код. Направете твърденията смислени и строги.
  • Тествайте широко различни пътища. Не отхвърляйте лесно кода като тестван, след като редовете са били засегнати. Често тестването на различни пътища изисква покриване на едни и същи редове няколко пъти.
  • Отнасяйте се към тестовете като към първокласни граждани на партньорска проверка.
  • Ретроспективно анализирайте грешки и работете върху подобряването на тестовия пакет, за да предотвратите същия тип грешки в бъдеще.

Изводът е, че колкото и да насърчавам разработчиците да разчитат на покритието на кода, имайте предвид, че има и други аспекти в играта по отношение на качеството на тестовия пакет.

В края на краищата, крайната цел на автоматизацията на тестовете е да даде възможност за бързо развитие с висока степен на увереност, а крайният определящ фактор за нейното качество е грешките да достигнат до крайния потребител.