Форумът на немския Python

От 2002 г. дискусии за езика за програмиране Python

форум

Развитие, управлявано от тестове

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

Къде виждате предимствата на py-теста или носа пред unittest?

Някой знае ли книгата Test Driven Development на Kent Beck?

Здравейте, това е добър легитимен въпрос.

Виждам го като BlackJack и Eydu.

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

Покритието трябва да ви освободи от работата по идентифициране на областите, които все още не са обхванати от единични тестове [2]. След това можете да използвате генерирания отчет, за да решите кои неща според вас трябва да бъдат обхванати и кои са незначителни за вас. Незначителни неща биха могли напр. Истински тривиални функции са, които не са променяни преди и "винаги" работят. - Но както BlackJack вече правилно е посочил, дяволът е в детайлите. Често точно тези неща, при които смятате, че „не е нужно да се вписвате“ и там се крият грешки. Затова обикновено се опитвам (в зависимост от сложността на софтуера) да постигна 100% покритие.

[1]: И през повечето време модулните тестове не се пишат успоредно на действителния софтуер, а много по-късно = седмици или дори месеци след това. Това е, че човек използва разработено с тестове, където първо се пишат модулните тестове и след това се прилагат съответните неща.

[2]: Такива области са не само във функция, но представляват цялото пространство на модула: С други думи, функциите, за които изобщо не съществува единичен тест, ви се показват от покритието. Така напр. Ако имам модул „foobar“, защото има „foo“ и „bar“ и съм написал само единичен тест за „foo“, последващото покритие ми показва „bar“ `не е изпълнен (= тестван) от модула за модулно тестване.

Въпросът във вашия пример „достъп до база данни и сокет“ е какво точно прави вашият софтуер? Ако вашият софтуер използва само компонентите (които не сте написани от вас), тогава не е нужно да ги тествате! Не е ваша работа да покривате библиотеки на трети страни с вашите модулни тестове. В замяна се моли да пише на Mocks.

Да предположим, че имате функция или клас, който осъществява достъп до сокетите чрез `socket` и в зависимост от резултатите изпълнява определени действия или променя състоянията. Сега идва проблемът, че когато го използвате за достъп до външен $ SERVER, който винаги трябва да връща определени данни. В този случай абстрахирате `socket` и очакваните данни от $ SERVER до степен, че вашата функция работи по същия начин, както ако действително сте използвали` socket` с $ SERVER.
По-конкретно, това означава, че имате необходимото Пренаписване на интерфейси на `сокет`, които спират да се свързват с $ SERVER, просто връщайки данните, които очаквате от реалния $ SERVER. Тогава цялото нещо трябва да бъде обещано на макет - манекен - което приписвате на вашата функция. Разбира се, трябва да пресъздадете този манекен, така че кодовете за грешки/изключение, които сте очаквали, да бъдат изхвърлени както при оригинала.

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

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

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

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

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