Unit тестване и в това, което макет обекти по примера на Google в подигравателна рамка

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

Уроци често използват при тяхното изпълнение от останалите класове, а те, от своя страна, включва много повече класове. Тъй като почти всички програми използват библиотеката и различните платформи - такава ситуация е естествено. Рядък функция е напълно изолиран от "външния свят" - но, че светът не трябва да бъдат обхванати от една единица тестове!

инструмент

Назначаване Google Тест също, че на Boost.Test или CppUnit - развитие на единица тестове. Всяко от тези библиотеки се справя с тази задача. Въпреки това, в теста Google включва специален добавка, наречена "Google C ++ подигравателни рамка" (по-специално в тази статия не е съществена разлика между понятията "рамка" и "библиотека" - извинявам се). Google ++ подигравателни Рамковата C (наричан по-просто Google Mock) не може да работи отделно от Google за изпитване, така че, ако възнамерявате да използвате тази услуга, е необходимо да се събират двата проекта. Не е трудно. Като цяло проектът има добра документация (на руски, също), на около 800 въпроса с Google Тест маркер на Stackoverflow. достатъчен брой членове. Ще разгледаме Google Мок, който ви позволява да създавате и използвате макет обекти в единица тестове.

За да се разбере защо се нуждаем от макет обекти в единица тестване, ние се нуждаем един прост пример.

Представете си, че ние разработваме клас, наречен Поръчка (персонализирани), и тя има няколко функции страни: проверка - за проверка поръчка, плащане - за плащане, да анулира - да се отмени, и толкова повече, че може да бъде свързан с поръчката, , Да приемем, че прилагането на методите е много тривиално. Единичните тестове трябва да проверяват - дали правилно изпълнява тези функции на различен набор от входни данни. Задачата на стандарта. Въпреки това, има един нюанс.

В рамките на изпълнението на методи на клас Ред, използвани клас Database обект (база данни). Този клас капсулира някои комуникация с магазин за данни, а всяка операция на Ордена, инициира повикване към този склад. Клас Database изпълнява неизвестен за нас, "магия", изисква "на живо" на база данни, и като цяло не са проектирани от нас и от други служби. Нашите тестове за единица продукт за Ордена не трябва да се проверяват дори Database клас. Още повече, че няма желание за реални тестове, за да персонализирате базата данни. Ето защо, от истинска класа база данни трябва да се отървете от - да го замени с някои "сляпо", пародия, която има абсолютно същия интерфейс като база данни, но в действителност прави или не прави нищо, това, което ни е нужно, за да се тества.

Забележка: Може да raskritikuete подобна връзка между Ордена и класовете на бази данни, но не разбирайте погрешно - това е само един пример.

По-долу традиционно представени класове въпросните: База данни и ред.

Клас Поръчка може да работи с различни приложения на базата данни и времето, което трябва да се направи "сляпо", тогава защо не го продаде себе си - без помощта на Google Мок. Просто се създаде клас DatabaseDummy. отворен интерфейс като база данни, и ще го използва в тестове. Това е логично идея, но тя не е подходяща за тестване. Ето защо:

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

2) DatabaseDummy клас не просто трябва да се направи нещо, той трябва да може да покаже различно поведение, така че ако той е истински Database. Това поведение трябва лесно да бъде описано по-специално тест. С други думи, DatabaseDummy клас не трябва да се държи като "сляпо", който винаги реагира по същия начин. И това е по-трудно да се постигне.

Описан DatabaseDummy клас - това е фалшив класа. но не и макети клас. И тези различни значения на понятията. Можете, разбира се въвеждат DatabaseDummy клас до точката, където тя ще отговаря на нашите изисквания, но ние в крайна сметка с допълнителен код, който също трябва да бъдат тествани (тук палачинка). И ако имате, в допълнение към базата данни, в изпълнение с участието и на други обекти, например за мрежата? Колко ще трябва да прекарват времето си, тъй като ние ще напишете кода? Ако използваме Google Мок, тогава всичко ще бъде много по-лесно. Google Мок ще ни даде готови макети класове с минимални усилия от нас сила.

Как напълно ще управлява макет клас Database клас, ако иска да повери Google Mock? Ето как:

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

Документацията се описва как да се създаде макет класове за различни поводи. Например, ако не използвате шаблони и наследство. Но в действителност, процесът на обучение за създаване на макети класове с помощта на Google Mock отнема няколко минути. Много по-интересно след това да ги използвате в тестове, като тяхното поведение е изцяло подчинена на нас. Освен управлението на макет сайт, можете да (и трябва) да определи предназначението им - колко пъти на метод за изпитване трябва да бъде извикана, какви аргументи следва да се прехвърля. Ако нещо от снимачната площадка на предположения не се изпълнява, тестът няма да бъде приет. Ние сега се обръщат към един прост пример.

Изпитване за проверка на метода на класа Поръчка. Вместо Database ще използва MockDatabase. Ние се провери дали метод make_query MockDatabase клас (а оттам и на класа Database), тя ще се нарича за тест само веднъж. Стойността на аргумента първи източник трябва да е равно на "заявка", а вторият аргумент, когато make_query разговор, ние не се интересуваме. Въпреки това, в резултат на make_query разговор, вторият аргумент трябва да бъде настроен на "резултат", както и методът трябва да се върне вярно.

На пръв поглед, израз EXPECT_CALL на изглежда сложно и претоварен. Въпреки това, ние бяхме в състояние да се опише в една линия make_query поведение на метода на класа Database (MockDatabase) в този конкретен тест. В допълнение към поведението, ние идентифицирахме редица предложения за това как да се използва метода make_query ще се случи: на броя на обажданията, стойностите на аргументите преминали. И всичко това в един ред. Всъщност, истинският тест ще има много EXPECT_CALL изрази, за да опиша други техники класове на бази данни, ще се определи последователността на тяхното повикване.

възможности за Google Макети при описването твърдяното поведение макет обекти е много обширна. SetArgReferee. DoAll. Назад - Тази функция на Google Mock библиотека. Пълен списък на страхотно, но тъй като тя може да бъде много трудно да се определи поведението на техните макети обекти. Въпреки това, в много случаи, това ще бъде достатъчно, и 10% от това, което е в Google Мок.

Имайте предвид, че поведението не е "програмирани" в моделната обекта, и се очаква в началото на следващия тест. Това позволява гъвкавост, за да персонализирате всеки отделен тест. Например, в следния пример, ние очакваме, че make_query метод по принцип не е причинена от:

Основната идея е, че с помощта на макети обекти, ние не се фокусира върху изпълнението им и на тяхното поведение и очаквания по отношение на използването на теста. Ние обичаме да се опише "външната среда" за код на тест, го изолира от всички зависимости, но имитират всичко като че ли "външна среда" съществува (библиотеки, бази данни и мрежата). Можете дори да създадете изключения, които са трудно да се възпроизведе в действителност.

За щастие, много от тях се развиват на тестове за своите програми. Но не винаги, когато това е хората да знаят за макет обекти. Или ги наричат ​​"фалшив" просто липсва възможностите, които те предоставят. Библиотека за създаване и управление макет обекти съществуват на всички езици. Например, в Питон (версия 3.3) е стандартен модул unittest.mock. В Java има JUnit и разширяване JMock. Дори и за езика C. е cmocka.org библиотека. който подкрепя макет обекти. Google C ++ подигравателни Рамковата не отстъпва на тях възможности, но остава сравнително лесен за употреба.

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

Документация за тестване рамка Google C ++