щепсел концепция

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

Фигура 1: Тестване реализира компонент

Тези други компоненти могат да предизвикат трудности при изпитване:

  1. Те не могат все още да бъдат изпълнени.
  2. Те могат да бъдат грешки, разрушаващи изпитания и фигуриращ какво грешката не е била причинена от теста, и зависимите компоненти, може да отнеме много време и усилия.
  3. Компоненти могат да възпрепятстват изпитване, когато това е наистина необходимо. Например, ако компонентът - базата данни на търговски, може да не бъде достатъчно лицензи за всички потребители. Друг пример: компонент може да бъде хардуер само на определени интервали в дадена лаборатория.
  4. Компоненти могат да бъдат толкова бавно тестване, което би било невъзможно да се извършат изпитванията, достатъчно често. Например, инициализация на базата данни може да отнеме пет минути.
  5. компонент в състоянието, може да бъде трудно да се сложи в която ще даде очаквания резултат от него. Например, преди да може да бъде обжалвано за тестване на обработката на съобщението "диск е пълен" за всички методи, за да пишат на диска. Как да се гарантира, че дискът ще бъде изпълнен точно по време на повикване правилния начин?

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

Фигура 2: тестване с щепсел компонент вместо компонента, от които зависи

В тапите има два недостатъка.

  1. Щепсели може да е скъпо (това е особено вярно за емулатори). Тъй като самите тапи са софтуер, те трябва да се поддържа.
  2. Щепсели могат да маскират грешки. Например, да предположим, че вашият компонент използва тригонометричните функции, но към днешна дата все още не е разработена съответната библиотека. Можете да използвате три теста за изчисляване на синуса на три ъгъла: 10 градуса, 45 градуса и 90 градуса. Ще намерите желаните стойности с помощта на калкулатор и изграждане на тапа синусова функция, която връща на следните входни параметри стойности 0.173648178, 0.707106781, и 1.0, съответно. Всичко работи добре, докато интеграцията на компонента в състава на крайния библиотеката, в която функцията синус се като вход на стойност в радиани и връща стойността -0,544021111 и 0.850903525 0.893996664. В резултат на това, ще откриете грешка в кода по-късно и да прекара повече усилия, отколкото бихме искали.

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

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

Вариант 1: Базата данни се използва за тестване и да се работи .. Наличието на базата данни не е нужно да се скрие от компонента. Можете дори да започне база данни компонент име:


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

Вариант 2: За да се провери в базата данни се заменя с коляно. компонент код трябва да бъде независим от този, с който става това: с действителната база данни или щепсела. Ето защо, кодът трябва да се прилага абстрактни методи на интерфейса:

При тестове, чифт ключове и стойности KeyValuePairs се осъществява с помощта на който и да е проста структура, такава таблица:
С изключение на периода на изпитване, компонент ще използва адаптер, който преобразува разговори KeyValuePairs в SQL: Описва

По компонент може да бъде един и същ дизайнер за тестване и действителна употреба. Този конструктор може да отнеме името на обекта, който реализира KeyValuePairs. Алтернативно, дизайнерът може да осигури интерфейс за тестване само и да се изиска от реалните компоненти на клиента преминали името на базата данни: \

Ето защо, от програмна гледна точка се оказа, че две от сценария на проекта, генерира същото на API, но един от тези сценарии са по-лесни за тестване. Също така имайте предвид, че някои тестове могат да използват истински база данни, а някои - все още мъниче.