NUnit - рамка единица тестване - мисли на глас

От себе си бих искал да се добави. Материалът е достатъчно полезна, що описах, и показва много възможности, ако преди това работа с NUnit като такъв не се провежда.

Е, това най-вероятно ще започне (ооо и namuchalas както съм сега с регистрация)

Така че, това, което се появява в NUnit версия 2.5?

Нови ограничения.
Дефинирани от потребителя за сравнение.
Възможност за определяне на точността на сравнението на числа с плаваща запетая, дата и час.
Параметрични тестове.
Combinatorial и по двойки тестове.
Теории.
Изключение Browser (в GUI-клиент).
Паралелно изпълнение на тестове (pnunit).

Ограничение на базата на модел

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

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

С този подход, методите за изпитване, са както следва:

Първата версия на NUnit тества с помощта на традиционния модел, и то все още е запазена за обратна съвместимост, но сега проверките на база модел, основан на използването на отделните обекти-ограничения (за изпълнение IConstraint интерфейс), всяка от които изпълнява определена проверка:

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

И накрая, NUnit включва специални класове са "синтактични помощници" - е и има, които ви позволяват да запише състоянието на почти "човешки" език:

По мое мнение, ограничение на базата на модел има само три плюс:

На първо място, по-лесни условия на зрителното възприятие - обаче, има различни мнения по този въпрос.

На второ място, по-лесни условия за писане - AreEqual () метод има 24 варианта, и е доста трудно да избера най-подходящия дори ако използвате Intellisense, и работа с ограничения и синтактични помощници правилен подбор на метода на е улеснено значително.

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

нови ограничения

Мисля, че сега е времето да се отговори на въпроса какво се появиха нови ограничения в NUnit 2.5. Тези ограничения са изброени по-долу:

RangeConstraint
Път Ограничения (SamePathConstraint, SamePathOrUnderConstraint)
Колекция Ограничения (UniqueItemsConstraint, CollectionOrderedConstraint)
ThrowsConstraint
DelayedConstraint

Разбира се, не разкрития тук, но да работи с NUnit сега е по-лесно!

Range Ограничение

RangeConstraint ви позволява да проверите, че стойността попада в този обхват:

Както можете да видите, че е само на кратко заместител на горната конструкция, както следва:

Ограничения пътя

SamePathConstraint ви дава възможност да се провери, че по същия начин:

SamePathOrUnderConstraint ви позволява да проверите, че действителната-пътека е същата, както и "долу" очаква посоки:

Също така нищо особено, просто удобен допълнение за сравнителни начини.

Колекция Ограничения

Много по-интересни са ограничения за сравняване колекции: UniqueItemsConstraint и CollectionOrderedConstraint.

UniqueItemsConstraint, както подсказва името, ви дава възможност да се провери, че колекцията съдържа само уникални елементи:

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

Хвърля Ограничение

Най-накрая се появи в ограничението NUnit за проследяване на изключения:

По-рано, за да се провери, че някои код хвърля изключение, че е необходимо да се използва само като обемисти структура:

Както можете да видите, използвайки Хвърля Ограничение трябва да напишете по-малко код, е възможно да се провери на няколко условия с изключения в един тест, и най-накрая, има повече възможности за проверка на съдържанието на обекта изключение!

Забавени Ограничение

И накрая, DelayedConstraint ви дава възможност да се провери, че събитието се случва, след определен период от време. Малък пример:

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

В този пример CommandProcessor клас изпълнява асинхронни команди обработка възложените му и в края на лечението разкритията преработени Flag. Проверка на факта, че заповедта е била обработена успешно, произведени чрез използване на DelayedConstraint, максималното време за изчакване е 1 секунда, анкетата на знамето направени с интервал от 100 милисекунди.

При сравняване на елементите в уравнението възможността за използване на дефинирани от потребителя за сравнение:

И още две възможности:

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

Преди версия 2.5 за изпълнение на такова сравнение трябва да се използват заобиколни като например използването на LINQ:

Но в същото време, в случай на повреда, вместо информативни мнения:

Samples.CollectionSamples.CustomComparerTest:
Очаквано и действително са двете стойности се различават в индекс [1]
String дължини са двете ленти 1. различават с индекс 0.
Очаква се на: «Б»
Но беше: «х»
---- ^

ние получихме неубедителен:

Samples.CollectionSamples.LinqComparerTest:
Очаква се на: True
Но беше: Фалшиви

Сравнение на числа с плаваща запетая

Както вече казах, в NUnit 2.5 имате възможност да определите точността, с която искате да сравните с плаваща запетая. За да направите това в три EqualConstraint модификатор добавя: В, Процент и Ulps.

В рамките на Модификатор ви позволява да определите абсолютната стойност на грешка, която ще сравни две числа с плаваща запетая:

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

Процент Модификатор ви позволява да посочите грешката в проценти:

Модификатор Ulps ви позволява да определите точността в "единици в последно място", т.е. В действителност, от гледна точка на грешки машина аритметични:

Сравнете датата и часа

В допълнение модификатори определени точност в сравнение с плаваща запетая в NUnit 2.5 появиха модификатори за определяне на точността при сравняването на дата и час. Например Life - тип DATETIME в SQL Server ви позволява да запишете датата и часа до 3 милисекунди, така че ако пишем стойност на датата и часа в SQL база данни сървър, и веднага след това се отчита стойността, в повечето случаи, получени от SQL стойност на сървъра няма да съответства на оригинала.

Това може лесно да се провери:

Както може да се очаква, тестът е неуспешен.

По-рано на този тест, за да работи, трябва да добавите ръчно код, за да конвертирате DateTime да SqlDateTime, сега можете да просто да добавите модификатор милисекунди:

Освен милисекунди модификатор има и други: дни, часове, минути, секунди и кърлежи.

Параметрични тестове до версия 2.5

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

Прости параметрични тестове

В NUnit 2.5 са "естествени" параметрични тестове и голям брой варианти за уточняване на аргументите на тези тестове.

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

Можете да се опрости този тест, като се използват само като един забавен дизайн:

Можете да посочите набор от тестови стойности в масива - и сега тя може да бъде параметри от всякакъв вид, например, една и съща десетични:

Можете да се свържете с всеки набор от тестови стойности допълнителни данни, например, уточни, че ако определен набор от аргументи, там е изключение или укажете в резултата:

И можете да определите типа IEnumerable имота, и в този случай ние не са ограничени в избора на източник на данни - те могат да бъдат взети от файл или изтегляне от базата данни:

Combinatorial и по двойки тестове

комбинаторна тестване

В допълнение към прости параметризираните тестове, NUnit ще бъде два вида тестове - е комбинаторни и по двойки-тестове.

С прости комбинаторни тестове - метод NUnit тест дава на вход всички възможни комбинации на входните параметри:

Резултатът от теста:

***** Samples.CombinatorialSamples.CombinatorialTest ( «по-», »-«, »х»)
а-х
***** Samples.CombinatorialSamples.CombinatorialTest ( «по-», »-«, »у»)
а-у
***** Samples.CombinatorialSamples.CombinatorialTest ( «по-», »+», »х»)
а + х
***** Samples.CombinatorialSamples.CombinatorialTest ( «по-», »+», »у»)
A + Y
***** Samples.CombinatorialSamples.CombinatorialTest ( «б», »-«, »х»)
б-х
***** Samples.CombinatorialSamples.CombinatorialTest ( «б», »-«, »у»)
Ь-у
***** Samples.CombinatorialSamples.CombinatorialTest ( «б», »+», »х»)
б + х
***** Samples.CombinatorialSamples.CombinatorialTest ( «б», »+», »у»)
б + у

Между другото, Combinatorial поле не е задължително, но аз предпочитам да го направя, за да се улесни разбирането.

По двойки тестове

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

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

***** Samples.PairwiseSamples.PairwiseTest ( «по-», »-«, »х»)
а-х
***** Samples.PairwiseSamples.PairwiseTest ( «по-», »+», »у»)
A + Y
***** Samples.PairwiseSamples.PairwiseTest ( «б», »-«, »у»)
Ь-у
***** Samples.PairwiseSamples.PairwiseTest ( «б», »+», »х»)
б + х
***** Samples.PairwiseSamples.PairwiseTest ( «б», »+», »у»)
б + у

Какво мога да използвам по двойки-тестове? Разбира се, за да се намалят разходите за изпълнение тест - дори и на малка извадка може да се види спечелване двойки-тест в сравнение с комбинаторна тест - от 5 до 8 комбинации!

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

Например, ако имаме 10 параметри, както и всеки параметър има 10 стойности, за комбинаторна тест броят на комбинациите ще бъде 1010, а за изпита за всички двойки, броят на комбинациите е само 155!
Най-общо казано, това не е съвсем вярно, правилно да се каже "не повече от 155". Минималният брой на тестовете, необходими за покриване на всички възможни двойки стойности може да се настрои само груба сила, която изисква огромно количество ресурси. Алгоритъмът се използва NUnit, който е изобретил и внедри в своята полезност, "Джени" Боб Дженкинс. В този алгоритъм генерира на случаен принцип няколко тестови случаи, а след това един от тях е избран, за да се осигури най-доброто покритие - и така, докато не бъдат "затворени", всички двойки от стойности.

Атрибути ValueSource, Range, Random и Поред тестове

атрибут ValueSource

А набор от ценности, които ще се използват за тестване на аргумента може да се настрои с ValueSource атрибут (точно както това се прави за тестови примери):

атрибут Range

С атрибута Range, можете да посочите диапазон от стойности на аргумента: