Развој тестиран од тестови - Страна 2 - Германски форум за пајтони
Од 2002 година, дискусии за програмскиот јазик Python
Тест-управувано развој
Да, можеби тестовите треба да бидат напишани при проширување на програма. Се чини дека тоа е разумен начин да се ограничи дали вреди тестирањето.
Каде ги гледате предностите на пи-тестот или носот во однос на единичниот тест?
Дали некој ја знае книгата Test Driven Development од Кент Бек?
Здраво, тоа е добро легитимно прашање.
Го гледам како Блек ackек и Ејду.
Покриеноста поврзана со единичните тестови треба првенствено да биде вознемирувачка за вас како програмер Ослабете ја работата за да утврдите дали сте ги покриле сите потребни случаи (за кои сметате дека се важни). Со многу големи апликации, често заборавате да напишете единица тестови за важни области на вашиот софтвер затоа што станува обемна, сложена и збунувачка [1].
Опфатот треба да ве ослободи од работата за идентификување на областите што сè уште не биле опфатени со единичните тестови [2]. Потоа, можете да го користите генерираниот извештај за да одлучите кои работи според вас мора да бидат опфатени и кои се занемарливи за вас. Занемарливите работи би можеле да бидат реални тривијални функции кои не се променети претходно и „секогаш“ функционираат. - Но, како што Блек ackек веќе правилно посочи, ѓаволот е во детали. Честопати токму тие работи мислат дека „не треба да се вклопувате“ и грешките се скриени таму. Затоа, обично се обидувам (во зависност од сложеноста на софтверот) да постигнам 100% покриеност.
[1]: И, поголемиот дел од времето, единичните тестови не се пишуваат паралелно со реалниот софтвер, туку многу подоцна = недели или дури месеци потоа. Тоа е дека се користи развој управуван од тестови, каде што прво се пишуваат единичните тестови, а потоа се спроведуваат соодветните работи.
[2]: Таквите области не се само во функција, туку го претставуваат целиот простор на модулот: Со други зборови, функциите за кои воопшто не постои единица за тестирање ви се прикажуваат со покриеноста. На пример, ако имам модул „foobar“ има „foo“ и „bar“ и напишав само единица тест за „foo“, последователното покривање ми покажува дека „ лентата "не беше извршена (= тестирана) од единичниот модул за тестирање.
Прашањето во вашиот пример „пристап до базата на податоци и приклучоците“ е што точно работи вашиот софтвер? Ако вашиот софтвер ги користи само компонентите (кои не сте напишани од вас), тогаш не мора да ги тестирате ниту нив! Не е ваша работа да покривате библиотеки од трети страни со тестовите за единици. За ова, тој бара да му напише на потсмев.
Да претпоставиме дека имате функција или класа што пристапува до приклучоците преку `socket` и, во зависност од резултатите, извршува одредени дејства или менува состојби. Сега се појавува проблем што кога ќе го користите за пристап до надворешен $ SERVER кој секогаш мора да враќа одредени податоци. Во тој случај, апстрахирате `сокет` и очекуваните податоци од $ SERVER до степен до кој вашата функција работи исто како и да сте користеле` socket` со $ SERVER.
Поточно, тоа значи дека ги имате потребните Препишување на интерфејсите на `сокетот` кои престануваат да се поврзуваат со $ SERVER, само враќајќи ги податоците што ги очекувате од реалниот $ SERVER. Тогаш целата работа е да ви се вети потсмев - атарот - што го припишувате на вашата функција. Се разбира, мора да го пресоздадете овој атарот, така што кодовите за грешки/исклучок што очекувавте да бидат фрлени како со оригиналот.
И тоа е местото каде што почнува да се комплицира. Темата навистина не е банална, и можете брзо да ги достигнете границите на остварливото (= пропорционалност). Не за ништо друго, пишувањето на тест средина може брзо да стане пообемно и покомплексно од околината што треба да се тестира. Тука треба да одмерите тежина помеѓу придобивката и пропорционалноста од случај до случај.
Исто така, треба да размислите дали софтверот се користи во безбедносна средина. Таму, областите поврзани со безбедноста на ММО не треба да се тестираат воопшто со потсмев, но треба да се постави вистинска постоечка средина за тестирање, специјално спиена за ова.
Она што е сè уште интересно во контекст на единичните тестови кои опфаќаат 100% сè е фактот дека единичните тестови исто така претставуваат спецификација, така да се каже. Вие ги специфицирате (апстрактно) сите интерфејси до најмалите детали; дури и да се чита само за програмерот.
Во овој контекст, би било интересно да има програми што исто така би генерирале спецификација во читлива форма од неа. и создавате програма што создава спецификација од неа
Звучи смешно, но тоа е сериозно наменето. Во магацинот Руби има (изолирани) размислувања во оваа насока. Постои и пакет за единици за тестирање што не зборува за тестови за пишување единици, туку за спецификации за пишување - Добро, ниедно свинче не може да чита освен оние што ги напишале „спецификациите“ или рубинските глувци