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

Когато пишете функция обикновено си представяме това, което тя трябва да направи, каква стойност да даде никакви аргументи.

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

Ако нещо не е наред, нали, да започне отново - за да видите резултата ... И така "до последна възможност."

Но като ръчно стартиране - много несъвършен начин за тестване.

При проверка на кода работата на ръка - това е лесно да се "nedotestirovat".

Например, запис функция е една. Писмен тест с различни аргументи. Покана е (а) функция работи, но е (б) не работи. Коригирана код - е работа F (б). като сме готови. Но те забравиха да ре-тест е (а) - Опа, това е възможно грешка в кода.

Автоматизирано тестване - е, когато тестовете са написани отделно от кода и винаги можете да ги изпълните и проверете всички важни случаи на употреба.

Ще разгледаме методиката на изпитване, която е включена в БДД - Поведение Driven развитие. БДД подход за дълго време и се използва успешно в много проекти.

БДД - това не е само тест. Тя е много повече.

БДД тестове - три в едно: И двата теста, както и документация, както и примери за използване.

Но достатъчно думи. Помислете примерите.

Да предположим, че искаме да развиваме функция Pow (х, н). което повдига число мощност х п. за простота n≥0.

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

Това описание се нарича спецификация (или, както казваме в общ език ", спец") и изглежда така:

В спецификацията, има три основни градивни елементи, които виждате в примера по-горе:

Тя определя това, което описват се използва за група "работен кон» - той блокира. В този случай, ние се опише функция Pow.

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

Кодът вътре в нея. Ако изпълнението е вярна, то трябва да се извърши без грешки.

Различни функции на форма отстоява. * Използват се провери дали Pow прави това, което е замислена. Досега ние се интересуваме от само един от тях - assert.equal. сравнява първия си спор с втория и дава съобщение за грешка, когато те не са равни. В този случай, той проверява, че в резултат на диаграма (2, 3) е равна на 8.

Има и други видове сравнения и проверки, които ще видим по-късно.

Като правило, за развитието на потока е както следва:

1. Писмено спецификация, която описва най-основните функции.
2. Това е първоначалното прилагане.
3. За да се провери съответствието със спецификацията, ние ще използваме рамките (в този случай Мока). Рамката се изпълнява всички тестове и показва грешки, когато те се появят. Когато грешката се поправя.
4. Спецификация разширява, тя добавя възможността, че все още не може да се поддържа от изпълнението.
5. Ходим на параграф 2, направи продажба. И така, "докрай".

Развитие се извършва итеративно. един пас след друг, докато спецификацията и изпълнението са завършени.

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

Ние ще използваме:

• Мока - тази библиотека съдържа общи функции за изпитване, включително и да го опиша.
• Чай - библиотеката поддържа различни функции за проверка. Има различни стилове "" Проверка на резултатите, които ще се учат по-късно, за сега, ние ще използваме само assert.equal.
• Sinon - емулация и лукав спуфинг функции "тапи", ще трябва по-късно.

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

Пример за HTML-страници на изпитването:

Тази страница може да бъде разделен на четири части:

1. блок - в него се свързваме библиотеки и стилове за тестване на кода ни там.
2. блок