Какво е тестване на единици?
Тестване на единици е дума, която се обяснява само ако човек разбира какво се разбира от Единица. Единицата е най-малкото възможно парче код, което може да бъде логически изолирано от системата. Това означава, че всяко парче код, което може да приема входни данни, да изпълнява задача и да генерира продукция, дори когато е независимо от цялата система или решение, може да бъде наречено като единица. Тестване на това парче код за генериране на очакван резултат на даден набор от входове се нарича Unit Testing.
Видове единични тестове
Нека да обсъдим някои от видовете единични тестове.
1) Ръчно тестване
Ръчното тестване на кода изисква от програмиста ръчно да отстрани грешки във всеки ред от кода и да го тества за точност. Може да е необходима стъпка по стъпка инструкция, както и ако функционалността е сложна.
2) Автоматизирано тестване
При тестване за автоматизация разработчикът записва код за тестване на кода. Обикновено това се подпомага чрез рамкови тестови рамки, които не са внедрени в производството. Друг път програмистът може да избере да пише тестов код без рамката и ръчно да го коментира преди внедряване.
Ръчното тестване очевидно изглежда отнема много време в повечето случаи. Но за някои случаи, когато писането на автоматични тестови случаи за покриване на всеки сценарий не е възможно, ръчният често е предпочитаният метод.
Защо е важно тестване на единица?
За да разберем важността на тестването на единици, трябва да разгледаме по-широката картина. Той е част от жизнения цикъл на разработката на софтуер. Нека разгледаме накратко останалите части, за да разберем по-добре ролята на тестването на единици.
Горното изображение е проста илюстрация на нормален жизнен цикъл на разработка на софтуер и процесите на тестване, свързани с него. Излишно е да казвам, че в зависимост от структурата на проекта, целият процес варира с добавянето и отстраняването на определени компоненти. Процесът на тестване, обаче, със сигурност включва четири типа, както е описано по-долу:
- Тестване на единици - елементарно ниво на целия процес на тестване. Това се извършва от разработчика на компонента или някой от неговите връстници. В последния случай той често се нарича Peer Testing в софтуерния свят.
- Integration Testing - Тестване на компонентния компонент с неговия непосредствен родителски модул. Целта е да се провери дали компонентният компонент се интегрира добре с другите компоненти и не е причинил неизправност на никой друг компонент.
- Тестване на системите - Тестване на цялата система, когато компонентът е поставен на мястото си.
- Тестване за приемане - обикновено се извършва от бизнес / клиенти, той проверява дали резултатът се изравнява с функционалността, очаквана от крайния потребител.
По този начин може да се види, че всички процеси на тестване разчитат на елементарното ниво на тестване. Ако елементарното ниво на тестване не е направено, всички други тестове могат да доведат до безполезни.
Сега да кажем, че имате код, който има две части
- Изчислете сложна лихва.
- Добавете лихвата към основната сума и изчислете обезщетението за падеж.
Да предположим, че не сте тествали единици нито един от тези компоненти и сте пристъпили директно към тестване на системата. При тестването на системата възниква грешка, че стойността на зрелостта е неправилна. Сега коя част от кода има грешка?
- Може да бъде в изчисляването на лихвата.
- Това може да бъде в прилагането на логиката на съставяне.
- Тя може да бъде в допълнение към лихвата към размера на главницата.
Вижте как сега увеличава усилията. Всичко това можеше да се избегне, ако и двата компонента на кода бяха тествани.
Защо е важно тестване на единица?
- Той коригира бъгове само в етапа на развитие. Това спестява много време, усилия и разходи. Представете си, че ако не бяха проведени единични тестове, кодът щеше да отиде и от екипа за осигуряване на качество за много прости проблеми.
- Добрите тестове на единица също служат за целите на подробна документация. Когато разработчикът пише тестови случаи за единица, той по невнимание пише очакваната функционалност на кода. Това не е нищо друго освен документация, която обяснява работата на кода.
- Улеснява модифицирането и поддържането на код. След като направите каквито и да било промени в кода, стартирайте тестовете отново и виола, всички дефекти се хващат без карани.
- Той също така налага модулност. Единичните тестове се провеждат на отделни компоненти, което означава, че кодът трябва да бъде възможно най-подробен. Това гарантира, че кодът е подходящо разделен на модули.
Другата страна на монетата
Има и някои недостатъци. Въпреки че предимствата претеглят недостатъците и винаги се препоръчва да тествате кода си, все пак има смисъл да знаете и двете лица на една и съща монета.
- Тестът на единици, как винаги е задълбочен, понякога може да не успее да улови всички грешки и в най-тривиалния код. Просто не е възможно да се оценят всички пътища за изпълнение. По този начин, единичните тестове често са директен и отрицателен сценарий.
- Това изисква от разработчика да мисли извън кутията и да се опита да разбие кода си. Това често е трудно, тъй като възприемането на програмист се пристрастява към кода.
Инструменти за тестване на единици
В индустрията има няколко инструмента за подпомагане на автоматизирани тестови случаи. Както е целта, те улесняват писането и изпълнението на тестовите случаи на единици по-лесно за разработчика. Съществува свят на рамки за тестване на единици при обезсърчаването на разработчиците. Някои от най-популярните и широко използвани инструменти са изброени по-долу.
JUnit
JUnit е безплатен инструмент за тестване на Java. Той автоматично се включва в много шаблони на проекти, достъпни с различни IDE за разработка на Java. Това, което прави JUnit специално, е, че тества първо данните и след това тества кода, след като вмъкне данните в него. Той също така предоставя твърдения за идентифициране на методите за изпитване.
NUnit
NUnit е да .Net както JUnit е към Java. Той има всички забележителни характеристики на JUnit, но за развитие в .Net език за програмиране. Той също така поддържа паралелно провеждане на тестовете.
PHPUnit
Подобно на JUnit и NUnit, PHPUnit е инструмент за PHP разработчици. Той също така поддържа всички елементарни характеристики на добър инструмент за тестване.
XUnit
Друга рамка, която е по-обща от своите колеги, е XUnit. Той поддържа множество езици като C ++, C #, ASP.Net и др. Освен това може да се похвали с подобни характеристики на други инструменти, налични на пазара.
Jtest
Parasoft Jtest е плъгин на трета страна, който използва рамки с отворен код като JUnit и добавя решения с едно щракване, за да улесни живота. С Jtest можете да генерирате автоматично тестови кодове за вашия код само с няколко кликвания. Чрез автоматизиране на тези задачи, разработчикът е свободен да работи върху бизнес логиката на тестовите случаи.
QUnit
Много популярна рамка за тестване на JavaScript. Той може да тества JavaScript код както от страна на клиента, така и от страна на сървъра.
жасмин
Друг много използван инструмент за тестване на рамки с JavaScript. Той има основна поддръжка на общността за Angular, React и т.н.
JMockIt
JMockIt е инструмент с отворен код, който също поддържа подиграване на API обажданията със синтаксис на запис и проверка.
Пример за единица тест
Много основно изискване за всеки тестов случай е кодът, който трябва да бъде тестван. Нека приемем, че имаме функция, която потвърждава дали телефонните номера са правилни (по отношение на формата) или не. В зависимост от географското местоположение този критерий може също да варира. Така че, няма да наблягаме на критериите. По-скоро ще се съсредоточим върху тестовия случай на единицата.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Сега трябва да тестваме това парче код.
Можем да го тестваме ръчно, като вмъкнем различни стойности и проверим резултата. Това може да изглежда лесно при първия поглед, но ще бъде повторена задача, ако се направи някаква промяна в кода.
Като алтернатива можем да напишем единичен тестов случай, който може да ми служи като валидатор, стига бизнес логиката да е същата. Тестовият случай на единицата няма да се промени, дори ако променим кода. Така че, нека да напишем единичен тестов случай за горния код.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
И така, как работи горният тестов код на теста? Забележете двата отчета за активите. Те се уверяват, че тестът преминава само ако двете линии получат вярно и невярно от съответните повиквания на функцията IsPhoneValid.
Ще попитате какви са ползите от писането на този тестов случай? Е, ако имате хиляди телефонни номера за валидиране във всеки реален сценарий, не е необходимо да проверявате ръчно всеки път, когато отстраняването на грешки в кода. Просто се обадете на тестовия код хиляди пъти и той ще ви каже кои тестове са преминали и кои са се провалили. Сега трябва само да инспектирате неуспешните.
Съвети за тестване на единици
- Винаги използвайте инструмент или рамка, поддържаща вашия език. Инструментите улесняват разработването на единични тестови случаи. В противен случай може да полагате допълнителни усилия.
- Въпреки че се препоръчва за всичко, понякога е удобно да пропускате кодове, които са прости и не влияят пряко върху поведението на системата. Например кодовете за геттер и сетер могат да бъдат по-малко фокусирани върху.
- Никога не пропускайте кодове, които пряко влияят върху системата или са от решаващо значение за внедряването на бизнес логиката.
- Използвайте тестови данни, наподобяващи производствени данни.
- Изолирайте кода си. Ако вашият код зависи от данните от базата данни, не пишете тестов случай, за да се обадите на базата данни и да получите стойности. Вместо това създайте интерфейс и се подигравайте с призивите на API и базата данни.
- Преди да коригирате грешка, произтичаща от тестване на единица, напишете тестовия случай, който разкрива дефекта. Има три причини за това:
- Ще можете да уловите регресионните дефекти, произтичащи от вашата корекция.
- Вашият тестов случай вече е по-изчерпателен.
- Често разработчикът е твърде мързелив, за да актуализира тестовите си случаи веднъж написани.
- В допълнение към писането на тестови случаи, които проверяват бизнес логиката, пишете случаи, които тестват и работата на вашия код. Особено когато кодовете включват цикъл, производителността е най-засегнатата област.
Неща, които трябва да запомните
- Тестовете на тестовете трябва да са независими от
- Кодът, който трябва да бъде тестван - Всяка промяна в кода не трябва да изисква промяна в тестовия случай, освен ако самата бизнес логика не се промени. Например, ако сега логиката изисква валиден телефонен номер да започва винаги с „+“, тогава тестовият случай на устройството трябва да бъде променен, в противен случай не.
- Другият код - Не трябва да има никакво взаимодействие или зависимост с друга стойност на код или база данни или нещо подобно. Единица трябва да бъде изолирана, когато се тества.
- Следвайте ясни и последователни конвенции за именуване на вашите тестови случаи. Улеснява проследяването на сценариите. Можете също да използвате инструменти за контрол на версиите, за да следите вашите тестови случаи.
- Никога не предавайте кода си на следващата фаза, докато не е направено, грешките са отстранени и повторно проверени.
- Най-важното е да го превърнете в навик. Това е практика на кодиране, която трябва да бъде включена. Колкото повече кодирате без тестване на единици, толкова по-предразположен е кодът ви към грешки.
Кариера в тестване на единица
Въпреки че изпитването на единици не е поле като цяло, все пак това е допълнителна стрелка във вашата кочан. Това е добра практика на кодиране и кога не се предпочитат добрите кодери?
заключение
Безспорно може да се заключи, че тестването на единица може да бъде понякога просто и сложно в други случаи. Точно тогава инструментите и рамките ви помагат. Дори при извършеното тестване на устройството, кодът не е напълно доказан за грешка. Тогава стартират следващите процедури за тестване на ниво. Сред всички тези несигурности единственото сигурно е, че е необходимо тестване на единица.
Препоръчителни статии
Това е ръководство за тестване на единици. Тук обсъдихме важността, съветите, инструментите, кариерата и видовете тестване на единици с неговите примери. Можете да разгледате и другите ни предложени статии, за да научите повече -
- Тестване на въпроси за интервю
- Приложение за уеб тестване
- Дефектен жизнен цикъл при тестване на софтуер
- Кариери в тестване на софтуер
- Списък на тестови рамки за Java