Какво е Unit Testing?

Какво е Unit Testing?

Модулното тестване е метод за тестване на софтуер, при който отделни единици или компоненти на кода— като функции, методи или класове — се тестват изолирано, за да се провери дали работят правилно. Целта е да се потвърди, че и най-малките части от приложението се държат според очакванията, без зависимости от външни системи.

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

Например, в Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

Този прост тест проверява дали add Функцията връща правилния резултат. Макар и тривиална, тя демонстрира идеята: логиката трябва да се провери независимо, преди да се интегрира с останалата част от системата.

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

Обяснение на видео за тестване на единици

Защо да извършвате Unit Testing?

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

Ето основните причини за извършване на модулно тестване в софтуерното инженерство:

• Ранно откриване на грешки – Проблемите се появяват близо до мястото, където са възникнали, което прави решенията им по-бързи и по-евтини.
• Подобрено качество на кода – Чистият, тестваем код често води до по-добра архитектура и по-малко скрити зависимости.
• Защита от регресия – Модулните тестове действат като предпазна мрежа по време на рефакторинга, гарантирайки, че старите функции ще продължат да работят.
• По-бързи цикли на развитие – Автоматизираните тестове скъсяват циклите на обратна връзка за осигуряване на качеството и намаляват разходите за ръчно тестване.
• По-висока увереност в отбора – С надеждно покритие на модулните тестове, разработчиците внедряват актуализации, знаейки, че те няма да нарушат съществуващите функции.

Накратко: Тестването на модули спестява време, намалява риска и подобрява надеждносттаТова трансформира тестването от болезнена последваща мисъл в проактивна инженерна практика.

Как да извършим модулно тестване?

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

Стъпка 1) Анализирайте единицата и дефинирайте случаите

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

Стъпка 2) Настройте тестовата среда

Изберете рамката, заредете минималните приспособления и изолиране на зависимости (мокове/заготовки/фалшификати). Поддържайте настройката лека, за да избегнете бавни и крехки тестове.

Стъпка 3) Напишете теста (AAA модел)

Подредете входните данни и контекстът → акт като се обадите на устройството → твърдя очаквания резултат. Предпочитайте твърдения за поведение пред вътрешни детайли за внедряване.

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

Стъпка 4) Стартирайте локално и в CI

Първо изпълнете тестове на вашата машина; след това ги изпълнете в CI за проверка на чистата среда. Бързо се справяйте с грешките; поддържайте лог файловете кратки и приложими.

Стъпка 5) Диагностициране на грешки, отстраняване и рефакториране

Когато тестът е неуспешен, поправете кода или теста, не и двете едновременно. След зелено, рефакторирайте с увереност – тестовете защитават поведението.

Стъпка 6) Повторно изпълнение, Revпреглед и поддържане

Стартирайте отново пълния пакет. Премахнете нестабилните тестове, дедуплицирайте фиксиращите елементи и ги наложете. прагове на покритие без да ги манипулирате. Маркирайте бавните тестове, за да се изпълняват по-рядко.

Професионални съвети:

• Запазете тестовете бързо (<200 ms всяка) и независим.
• Тестове за имена за поведение (Например, test_total_includes_tax).
• Отнасяйте се към нестабилността като към грешка; поставете я под карантина, отстранете първопричината и след това я активирайте отново.

Какви са различните техники за модулно тестване?

Единичните тестове са най-ефективни, когато се комбинират техники за интелигентно проектиране на тестове с разумни цели за покритиеСтремете се към широта на дейността, където е важна, към дълбочина, където рискът е най-висок, и се съпротивлявайте на капана „100% или провал“.

- Техники за модулно тестване са основно категоризирани в три части:

1. Изпробване на черна кутия което включва тестване на потребителския интерфейс, заедно с входните и изходните данни
2. Тестване на бяла кутия включва тестване на функционалното поведение на софтуерното приложение
3. Тестване на сива кутия използва се за изпълнение на тестови пакети, тестови методи и тестови случаи, както и за извършване на анализ на риска

Покритието е водещ индикатор, а не финалната линия. Използвайте го, за да намерете слепи петна, а не за да се манипулира числото. Техниките за покритие на кода, използвани в модулното тестване, са изброени по-долу:

• Покритие на изявлението
• Покритие на решението
• Покритие на клонове
• Покритие на състоянието
• Покритие на краен автомат

За повече информация относно покритието на кода вижте https://www.guru99.com/code-coverage.html

Каква е ролята на подигравките и заглушаванията в модулното тестване?

Единичните тестове трябва да се фокусират само върху тествания код — не неговите зависимости, Ето къде макети намлява мъничета Влезте. Тези „тестови дубльори“ заместват реални обекти, така че можете да изолирате поведението, да контролирате входните данни и да избягвате бавни или нестабилни тестове.

Защо да използваме тест Doubles?

• Изолация – Тествайте само устройството, а не базата данни, мрежата или файловата система.
• Детерминизъм – Контролирайте резултатите и страничните ефекти, така че резултатите да са последователни.
• Скорост – Тестовете се изпълняват за милисекунди, когато не докосват външни системи.
• Симулация на гранични случаи – Лесно имитиране на грешки (напр. изчакване на API), без да се чака за тях в реалния живот.

Тапи

A кочан е опростен заместител, който връща фиксиран отговор. Той не записва взаимодействията — просто предоставя консервирани данни.

Пример (Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

Подиграва се

A имитация е по-мощен: може да проверява взаимодействия (напр. „този метод извикан ли е с X?“).

Пример (JavaСкрипт с Jest):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

Тук, имитация проверява дали имейл услугата е била извикана правилно — нещо, което един stub не може да направи.

Често срещани клопки

• Прекалено подигравателно – Ако всеки сътрудник е подиграван, тестовете стават крехки и обвързани с детайлите на внедряването.
• Тестване на макети вместо поведение – Фокусирайте се върху резултатите (състояние/възвръщаемост), а не върху взаимодействията, когато е възможно.
• Изтичащ код за настройка – Поддържайте макети/заготовки леки; използвайте помощни елементи или фиксиращи елементи за по-добра четливост.

Практични правила

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

В крайна сметка: Подигравките и заяждането са поддържащи актьори, не звездите. Използвайте ги, за да изолирате устройството си, но не им позволявайте да отвлекат тестовия пакет.

Кои са често срещаните инструменти за модулно тестване?

Налични са няколко софтуера за автоматизиран модулен тест, които да подпомогнат тестването на модули в софтуерното тестване. Ще предоставим няколко примера по-долу:

1. JUnitJunit е безплатен инструмент за тестване, използван за Java език за програмиране. Той предоставя твърдения за идентифициране на метода за тестване. Този инструмент първо тества данните и след това ги вмъква в кода.
2. NUnitNUnit е широко използвана рамка за модулно тестване за всички .NET езици. Това е инструмент с отворен код, който позволява ръчно писане на скриптове. Поддържа тестове, базирани на данни, които могат да се изпълняват паралелно.
3. PHPUnitPHPUnit е инструмент за модулно тестване за PHP програмисти. Той взема малки части от код, наречени модули, и тества всяка от тях поотделно. Инструментът също така позволява на разработчиците да използват предварително дефинирани методи за твърдение, за да твърдят, че дадена система се държи по определен начин.

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

Разработка, управлявана от тестове (TDD) и тестване на единици

Модулното тестване в TDD включва широко използване на тестови рамки. Използва се рамка за модулно тестване, за да се създадат автоматизирани модулни тестове. Рамките за модулно тестване не са уникални за TDD, но са от съществено значение за него. По-долу разглеждаме някои от предимствата, които TDD предлага в света на модулното тестване:

• Тестовете се пишат преди кода
• Разчитайте в голяма степен на тестови рамки
• Всички класове в приложенията са тествани
• Възможна е бърза и лесна интеграция

Ето някои предимства на TDD:

• Насърчава малки, тестваеми модули и прости дизайни.
• Предотвратява прекомерното инженерство; изграждате само това, което тестът изисква.
• Осигурява „жива“ предпазна мрежа за рефакторите.

Експертен съветИзберете TDD, когато пожелаете стегната обратна връзка за дизайна на ниво код и бърз, постепенен напредък по модулите.

Защо да интегрираме модулни тестове в CI/CD?

Модулните тестове предоставят най-голяма стойност, когато са свързани директно към конвейер за непрекъсната интеграция и непрекъсната доставка (CI/CD)Вместо да бъдат второстепенна мисъл, те се превръщат в качествена порта който автоматично валидира всяка промяна преди изпращането ѝ.

Ето са причините за интегриране на модулни тестове в CI/CD конвейери:

• Незабавна обратна връзка – Разработчиците разбират в рамките на минути дали промяната им е нарушила нещо.
• Shift-ляво качество – Грешките се откриват по време на commit-ването, а не след пускането им.
• Увереност в внедряванията – Автоматизираните проверки гарантират, че „зелените конструкции“ са безопасни за изграждане.
• Мащабируемо сътрудничество – Екипи от всякакъв размер могат да обединяват код, без да се намесват един в друг.

Мит за модулното тестване

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

„Изисква време, а аз винаги съм претоварен. Кодът ми е изключително стабилен! Нямам нужда от модулни тестове.“

Митовете по своята същност са неверни предположения. Тези предположения водят до порочен кръг, както следва –

Истината е, че модулното тестване увеличава скоростта на разработка.

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

Предимство на модулното тестване

• Разработчиците, които искат да научат каква функционалност се предоставя от единица и как да я използват, могат да разгледат тестовете на единица, за да придобият основно разбиране за API на единицата.
• Модулното тестване позволява на програмиста да рефакторира кода на по-късна дата и да се увери, че модулът все още работи правилно (т.е. Регресионно тестване). Процедурата е да се напишат тестови случаи за всички функции и методи, така че когато промяната причини грешка, тя може бързо да бъде идентифицирана и коригирана.
• Поради модулния характер на модулното тестване, можем да тестваме части от проекта, без да чакаме други да бъдат завършени.

Недостатъци на модулното тестване

• Не може да се очаква модулното тестване да улови всяка грешка в програмата. Не е възможно да се оценят всички пътища на изпълнение, дори в най-тривиалните програми.
• Модулното тестване по своята същност се фокусира върху единица код. Следователно, то не може да улови грешки при интеграция или грешки на системно ниво.

Препоръчително е модулното тестване да се използва заедно с други тестови дейности.

Най-добри практики за модулно тестване

• Единичните тестове трябва да бъдат независими. В случай на подобрения или промени в изискванията, те не трябва да бъдат засегнати.
• Тествайте само един код наведнъж.
• Следвайте ясни и последователни конвенции за именуване за вашите модулни тестове
• В случай на промяна на кода в който и да е модул, уверете се, че има съответна единица Тестов случай за модула и модулът преминава тестовете, преди да промени изпълнението
• Грешките, идентифицирани по време на тестване на единица, трябва да бъдат коригирани, преди да се премине към следващата фаза в SDLC
• Възприемете подхода „тест като ваш код“. Колкото повече код пишете без тестване, толкова повече пътища трябва да проверите за грешки.

Въпроси и Отговори

Oбобщение