j-unit тестове

7
Какво представляват JUnit тестовете?

Upload: georgi-mirchev

Post on 13-Jun-2015

174 views

Category:

Education


0 download

DESCRIPTION

Описание на J-Unit тестовете

TRANSCRIPT

Page 1: J-Unit тестове

Какво представляват JUnit тестовете?

Page 2: J-Unit тестове

Това е framework за тестване на парчета от код(класове или методи) за Java, който също така се използва в много други езици като:C# (NUnit) Адрес:

C++ (CPPUnit)

Fortran (fUnit)

Delphi (DUnit)

Free Pascal (FPCUnit)

JavaScript (JSUnit)

Objective-C (OCUnit)

Perl (Test::Class and Test::Unit)

PHP (PHPUnit)

Python (PyUnit)

R (RUnit)

Page 3: J-Unit тестове

Цели:

- При правилно планиране да улесни живота на програмиста

- Бързо и качествено писане на код

- Лесно установяване и поправяне на възникналите грешки

- По-малка вероятност за изскачане на неочаквани грешки по време на изпълнение на кода

Page 4: J-Unit тестове

Как работи JUnit?

Като се създават тестови класове, в които се:

- Създават тестови случаи на дадени методи

- Извикват някои от вградените функции на JUnit като (assertEquals(), fail(), suite(), setUp(), tearDown())

- Извикват методи на други тестови класове

- Създават т.нар. Фалшиви обекти

Page 5: J-Unit тестове

Какво да тестваме?Принципът Right-BICEP:

- Right – резултатите правилни ли са ?

-B(boundary) – всички гранични условия правилни ли са ?

-I(inverse) – можете ли да проверите връзките между класовете в обратен ред ?

-C(cross-check) – можете ли да проверявате резултатите по различен начин ?

-E(error) – може те ли да предизвиквате възникването на грешки ?

-P(performance) – производителността в границите ли е ?

Page 6: J-Unit тестове

По какво да познаем добрите тестове?

Принципът A-TRIP:

- A – automatic – автоматичен

-T – Thorough – обстоен

-R – Repeatable – лесно повторяем

-I – Independent - независим

-P – Professional – професионално написан

Page 7: J-Unit тестове

Допълнителни нещаТестовият код при по-големите проекти е КОЛКОТО кодът на самия проект.

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

Обичайна практика е при Test-Driven дизайна тестовите методи да биват създавани преди методите, които тестват.