TDD және бірлік сынағы дегеніміз не [аудару]

Бұл мақала The Complete Software Career Guide кітабының тарауының бейімделуі. Оның авторы Джон Сонмез оны жазып, кейбір тарауларын өзінің веб-сайтында орналастырады.

Жаңадан бастаушыларға арналған қысқаша глоссарий

Бірлік сынағы немесе бірлік сынағы – бағдарламаның бастапқы codeының жеке модульдерінің дұрыстығын тексеруге мүмкіндік беретін бағдарламалаудағы процесс. Идея - әрбір тривиальды емес функция немесе әдіс үшін сынақтар жазу. Регрессиялық тестілеу – бастапқы codeтың әлдеқашан тексерілген аймақтарындағы қателерді анықтауға бағытталған бағдарламалық қамтамасыз етуді тестілеудің барлық түрлерінің жалпы атауы. Мұндай қателер - бағдарламаға өзгертулер енгізілгеннен кейін жұмысын жалғастыру керек нәрсе жұмысын тоқтатқан кезде - регрессия қателері деп аталады. Қызыл нәтиже, сәтсіздік - сынақтың сәтсіздігі. Күтілетін нәтиже мен нақты нәтиже арасындағы айырмашылық. Жасыл нәтиже, өту - оң сынақ нәтижесі. Нақты нәтиже алынғаннан еш айырмашылығы жоқ. *** Менің сынаққа негізделген даму (TDD) және бірлікті тестілеумен өте аралас қарым-қатынасым бар, махаббаттан жек көрушілікке және қайтадан кері қайтады. Мен жанкүйер болдым және сонымен бірге осы және басқа да «үздік тәжірибелерді» қолдануға күдікті болдым. Менің көзқарасымның себебі бағдарламалық жасақтаманы әзірлеу процестерінде күрделі мәселенің пайда болуына негізделген: әзірлеушілер, кейде менеджерлер белгілі бір құралдар мен әдістемелерді «үздік тәжірибелерге» жататындықтан ғана пайдаланады. Оларды пайдаланудың нақты себебі әлі белгісіз. Бір күні мен белгілі бір жобада жұмыс істей бастадым және бұл процесте біз көптеген бірлік сынақтарымен қамтылған codeты өзгертетініміз туралы хабардар болдым. Әзіл емес, олардың саны шамамен 3000 болды.Бұл әдетте жақсы белгі, әзірлеушілер озық әдістемелерді қолданып жатқанының белгісі. Бұл тәсілмен code көбінесе құрылымдалған және ол жақсы ойластырылған архитектураға негізделген. Бір сөзбен айтқанда, сынақтардың болуы мені қуантты, өйткені бұл менің бағдарламашылардың тәлімгері ретіндегі жұмысымды жеңілдететін болса керек. Бізде бірлік сынақтары болғандықтан, маған тек әзірлеушілер тобын оларға қолдау көрсету және өз codeымызды жазуды бастау керек болды. Мен IDE (біріктірілген әзірлеу ортасы) аштым және жобаны жүктедім. Бұл үлкен жоба болды! Мен «бірлік сынақтары» деп белгіленген қалтаны таптым. «Тамаша» деп ойладым мен. - Оны іске қосып, не болатынын көрейік. Бұл бар болғаны бірнеше minutesты алды, және мені таң қалдырғаны, барлық сынақтар өтті, бәрі жасыл түсті ( «жасыл» - сынақтың оң нәтижесі. Код күткендей жұмыс істеп тұрғанын білдіреді. Қызыл түс «сәтсіздікті» немесе сәтсіздікті білдіреді, содан кейін code дұрыс жұмыс істемейтін жағдай бар - аудармашының ескертпесі ). Олардың барлығы сынақтан өтті. Осы кезде ішімдегі скептик оянып кетті. Қалайша, үш мың бірлік сынақ, және олар барлығын бірден қабылдады - және оң нәтиже берді? Ұзақ тәжірибемде codeта бірде-бір теріс бірлік сынағы жоқ жобада жұмыс істей бастаған кезді есіме түсіре алмадым. Енді не істеу керек? Қолмен тексеріңіз! ChY бір кездейсоқ сынақты таңдады, ең айқын емес, бірақ оның не тексеріп жатқаны бірден белгілі болды. Бірақ онымен жұмыс істей отырып, мен абсурдты байқадым: сынақта күтілетін нәтижемен салыстырулар жоқ (бекітеді)! Яғни, іс жүзінде ештеңе тексерілмеген ! Сынақта белгілі бір қадамдар болды, олар жүзеге асырылды, бірақ тест соңында ол нақты және күтілетін нәтижелерді салыстыру керек жерде ешқандай тексеру болмады. «Тест» ештеңені сынамады. Мен тағы бір сынақты аштым. Одан да жақсы: нәтижемен салыстыру операторына түсініктеме берілді. Керемет! Бұл сынақтан өтудің тамаша тәсілі, оның сәтсіздігін тудыратын codeты түсіндіріңіз. Мен басқа сынақты тексердім, содан кейін басқасын... Олардың ешқайсысы ештеңені тексермеді. Үш мың сынақ, және олардың барлығы мүлдем пайдасыз. Бірлік тесттерін жазу мен бірлік тестілеу мен сынаққа негізделген әзірлеуді (TDD) түсіну арасында үлкен айырмашылық бар.

Бірлік сынағы дегеніміз не?

Бірлікті тестілеудің негізгі идеясы codeтың ең кішкентай «бірлігін» сынайтын сынақтарды жазу болып табылады. Бірлік сынақтары әдетте қолданбаның бастапқы codeы сияқты бірдей бағдарламалау тілінде жазылады. Олар осы codeты тексеру үшін тікелей жасалады. Яғни, бірлік сынақтары басқа codeтың дұрыстығын тексеретін code болып табылады. Мен «тест» сөзін контексте өте еркін қолданамын, өйткені бірлік тестілері қандай да бір мағынада сынақ емес. Олар ештеңені бастан кешірмейді. Менің айтқым келгені, сіз бірлік сынамасын іске қосқанда, әдетте кейбір code жұмыс істемейтінін таппайсыз. Сіз мұны сынақты жазу кезінде анықтайсыз, өйткені сынақ жасыл түске боялғанша codeты өзгертесіз. Иә, code кейінірек өзгеруі мүмкін, содан кейін сынақ сәтсіз болуы мүмкін. Сонымен, бұл мағынада бірлік сынағы регрессия сынағы болып табылады. Бірлік сынағы сіз орындайтын бірнеше қадамдарыңыз бар және бағдарламалық құралдың дұрыс жұмыс істеп тұрғанын немесе жұмыс істемейтінін көретін әдеттегі сынақ сияқты емес. Бірлік сынағын жазу процесі кезінде сіз codeтың өзі істеу керек нәрсені жасайтынын немесе орындамайтынын анықтайсыз және сынақтан өткенше codeты өзгертесіз. Неліктен бірлік сынағын жазып, оның өткенін тексермеске? Егер сіз бұл туралы ойласаңыз, онда бірлік сынақтары өте төмен деңгейде белгілі бір code модульдері үшін абсолютті талаптардың қандай да бір түріне айналады. Бірлік сынамасын абсолютті спецификация ретінде қарастыруға болады . Бірлік сынағы осы шарттарда осы нақты кірістер жиынымен codeтың осы бірлігінен алу керек шығыс бар екенін анықтайды. Шынайы бірлік тестілеу codeтың ең кіші когерентті бірлігін анықтайды, ол көптеген бағдарламалау тілдерінде - кем дегенде an objectіге бағытталған - класс болып табылады.

Кейде бірлік тестілеу деп нені атайды?

Бірліктерді тестілеуді интеграциялық тестілеумен жиі шатастырады. Кейбір «бірлік сынақтары» бірнеше сыныпты тексереді немесе codeтың үлкен бірліктерін тексереді. Көптеген әзірлеушілер бірлік сынақтарын жазады деп мәлімдейді, ал шын мәнінде олар төмен деңгейлі ақ жәшік сынақтарын жазады. Бұл жігіттермен ұрыспаңыз. Тек олардың шын мәнінде интеграциялық сынақтарды жазатынын біліңіз, ал шынайы бірлік сынақтары codeтың ең кіші бірлігін басқа бөліктерден оқшаулап тексереді. Көбінесе бірлік сынағы деп аталатын тағы бір нәрсе - күтілетін мәнді тексермей бірлік сынақтары. Басқаша айтқанда, ештеңені тексермейтін бірлік сынақтары. Біріктірілген немесе біріктірілмеген кез келген сынақ тексерудің қандай да бір түрін қамтуы керек - біз оны күтілетін нәтижеге қарсы нақты нәтижені тексеру деп атаймыз. Дәл осы салыстыру сынақтың өтуін немесе өтпеуін анықтайды. Әрқашан өтетін сынақ пайдасыз. Әрқашан сәтсіз болатын сынақ пайдасыз.

Бірлік сынауының мәні

Неліктен мен бірлік тестілеуге әуесқоймын? Басқа codeтан оқшауланған ең кішкентай блокты емес, codeтың үлкен бөлігін, яғни «бірлік сынағы» тестілеуді қамтитын жалпылама тестілеуді шақыру неге зиянды? Кейбір сынақтарым алынған және күтілетін нәтижелерді салыстырмаса, қандай мәселе бар? Кем дегенде, олар codeты орындайды. Мен түсіндіруге тырысамын. Бірлікті сынауды орындаудың екі негізгі себебі бар. Біріншісі - code дизайнын жақсарту. Бірлік тестілеу шынымен тестілеу емес деп айтқанымды есіңізде ме? Сәйкес бірлік сынақтарын жазғанда, сіз өзіңізді codeтың ең кіші бірлігін оқшаулауға мәжбүрлейсіз. Бұл әрекеттер codeтың құрылымындағы проблемаларды табуға әкеледі. Сізге сынақ сыныбын оқшаулау және оның тәуелділіктерін қоспау өте қиын болуы мүмкін және бұл сіздің codeыңыздың тым тығыз байланыстырылғанын түсінуге әкелуі мүмкін. Сіз сынауға тырысып жатқан негізгі функцияның бірнеше модульдерді қамтитынын байқасаңыз, codeыңыз жеткілікті түрде үйлесімді емес деп санайсыз. Бірлік сынағы жазу үшін отырғанда, сіз кенеттен codeтың не істеу керектігін білмейсіз (және маған сеніңіз, солай болады!) Тиісінше, ол үшін бірлік сынағы жазуға ешқандай мүмкіндік жоқ. Және, әрине, сіз codeты жүзеге асыруда нақты қатені таба аласыз, өйткені бірлік сынағы сізді қораптан тыс ойлауға және сіз қарастырмаған әртүрлі кірістер жиынын сынауға мәжбүр етеді. Бірлік сынақтарын жасау кезінде «codeтың ең кіші бірлігін басқалардан оқшаулап сынау» ережесін қатаң ұстанатын болсаңыз, сіз осы codeпен және сол модульдердің дизайнымен байланысты барлық мәселелерді таба аласыз. Бағдарламалық жасақтаманы әзірлеудің өмірлік циклінде бірлік тестілеу тестілеу әрекетінен гөрі бағалау әрекеті болып табылады. Бірліктерді тестілеудің екінші негізгі мақсаты бағдарламалық жасақтама әрекетінің төмен деңгейлі спецификациясы ретінде әрекет ете алатын регрессия сынақтарының автоматтандырылған жинағын құру болып табылады. Бұл нені білдіреді? Қамырды илегенде оны сындырмайсыз. Осы тұрғыдан алғанда, бірлік сынақтары сынақтар, нақтырақ айтқанда, регрессиялық сынақтар болып табылады. Дегенмен, бірлікті тестілеудің мақсаты жай ғана регрессия сынақтарын құру емес. Тәжірибеде бірлік сынақтары регрессияларды сирек ұстайды, өйткені сіз сынап жатқан code бірлігін өзгерту әрқашан дерлік бірлік сынағының өзінде өзгерістерді қамтиды. Регрессиялық тестілеу жоғары деңгейде codeты «қара жәшік» ретінде сынаған кезде әлдеқайда тиімдірек, өйткені бұл деңгейде codeтың ішкі құрылымын өзгертуге болады, ал сыртқы мінез-құлық өзгеріссіз қалады деп күтілуде. Бірлік сынақтары өз кезегінде ішкі құрылымды тексереді, осылайша құрылым өзгерген кезде бірлік сынақтары сәтсіздікке ұшырамайды. Олар жарамсыз болып қалады және енді өзгерту, лақтыру немесе қайта жазу қажет. Сіз енді көптеген тәжірибелі бағдарламалық жасақтаманы әзірлеушілерге қарағанда бірліктерді тестілеудің шынайы мақсаты туралы көбірек білесіз.

Тестке негізделген даму (TDD) дегеніміз не?

Бағдарламалық жасақтаманы әзірлеу процесінде жақсы сипаттама алтынмен тең. TDD тәсілі - кез келген codeты жазбас бұрын, алдымен спецификация ретінде қызмет ететін сынақты жазасыз, яғни codeтың не істеу керектігін анықтаңыз. Бұл бағдарламалық жасақтаманы әзірлеудің өте күшті тұжырымдамасы, бірақ ол жиі дұрыс емес пайдаланылады. Әдетте, сынаққа негізделген әзірлеу қолданбалы codeты жасауды бағыттау үшін бірлік сынақтарын пайдалануды білдіреді. Бірақ іс жүзінде бұл тәсілді кез келген деңгейде қолдануға болады. Дегенмен, бұл мақалада біз қолданбамыз үшін бірлік сынағы қолданып жатырмыз деп есептейміз. TDD тәсілі барлығын өз бетінше өзгертеді және алдымен codeты жазып, содан кейін сол codeты сынау үшін бірлік сынақтарын жазудың орнына алдымен бірлік сынағын жазасыз, содан кейін сол сынақты жасыл ету үшін codeты жазасыз. Осылайша, бірлік тестілеу codeты әзірлеуді «жеткізеді». Бұл процесс қайта-қайта қайталанады. Сіз codeтың не істеу керектігі туралы көбірек функционалдылықты анықтайтын басқа сынақ жазасыз. Содан кейін сынақтың сәтті аяқталуын қамтамасыз ету үшін codeты жазасыз және өзгертесіз. Жасыл нәтижеге ие болғаннан кейін сіз codeты қайта өңдеуді бастайсыз, яғни оны қысқаша ету үшін оны қайта өңдеу немесе тазалау. Процестердің бұл тізбегі жиі «Қызыл-Жасыл-Рефакторинг» деп аталады, себебі алдымен бірлік сынағы сәтсіз аяқталды (қызыл), содан кейін code сынаққа бейімделу үшін жазылады, оның сәтті өткеніне көз жеткізеді (жасыл) және соңында code оңтайландырылған ( рефакторинг).

TDD мақсаты қандай?

Бірліктерді сынау сияқты сынаққа негізделген әзірлеу (TDD) қате пайдаланылуы мүмкін. Жасаған ісіңізді «TDD» деп атау өте оңай, тіпті мұны неліктен осылай істеп жатқаныңызды түсінбестен тәжірибені орындаңыз. TDD ең үлкен құндылығы - сапа спецификацияларын шығару үшін сынақтар орындалады. TDD негізінен codeтау жазылмас бұрын автоматты түрде тексерілуі мүмкін нақты спецификацияларды жазу тәжірибесі болып табылады. Тесттер ең жақсы сипаттамалар болып табылады, өйткені олар өтірік айтпайды. Олар сізге екі апталық азаптан кейін «мен бұл мүлде айтқым келген жоқ» деген codeпен айтпайды. Тесттер дұрыс жазылғанда не тапсырады, не өтпейді. Тесттер белгілі бір жағдайларда не болуы керек екенін анық көрсетеді. Осылайша, TDD мақсаты - оны жүзеге асыруды бастамас бұрын бізге нені жүзеге асыру керек екендігі туралы толық түсінік беру. Егер сіз TDD-мен жұмысты бастасаңыз және тест нені тексеру керектігін анықтай алмасаңыз, сізге көбірек сұрақтар қою керек. TDD тағы бір маңызды рөлі codeты сақтау және оңтайландыру болып табылады. Кодқа қызмет көрсету қымбат. Мен ең жақсы бағдарламашы қандай да бір мәселені шешетін ең қысқа codeты жазатын адам деп қалжыңдаймын. Немесе бұл мәселені шешудің қажеті жоқ екенін дәлелдейтін адам және осылайша codeты толығымен алып тастайды, өйткені қателер санын азайтудың және қосымшаны ұстау құнын төмендетудің дұрыс жолын тапқан осы бағдарламашы. TDD пайдалану арқылы сіз ешбір қажетсіз code жазбағаныңызға толық сенімді бола аласыз, өйткені сіз тек сынақтардан өту үшін code жазасыз. YAGNI деп аталатын бағдарламалық жасақтаманы әзірлеу принципі бар (сізге ол қажет емес). TDD YAGNI алдын алады.

Типтік сынаққа негізделген әзірлеу (TDD) жұмыс процесі

TDD мағынасын таза академиялық тұрғыдан түсіну қиын. Сонымен, TDD сеансының мысалын қарастырайық. Үстелге отырып, пайдаланушыға қолданбаға кіруге және оны ұмытып қалса, құпия сөзін өзгертуге мүмкіндік беретін мүмкіндіктің жоғары деңгейлі дизайны болады деп ойлайтын нәрсені жылдам сызбаңызды елестетіп көріңіз. Сіз жүйеге кіру процесінің барлық логикасын өңдейтін сыныпты жасай отырып, кіру функциясын бірінші іске асырудан бастауды шешесіз. Сіз өзіңіздің таңдаулы редакторыңызды ашып, «Бос кіру пайдаланушының жүйеге кіруіне жол бермейді» деп аталатын бірлік сынағын жасайсыз. Сіз алдымен Login сыныбының данасын жасайтын бірлік сынақ codeын жазасыз (оны әлі жасамағансыз). Содан кейін бос пайдаланушы аты мен құпия сөзді беретін Login сыныбында әдісті шақыру үшін code жазасыз. Соңында, бос логині бар пайдаланушының жүйеге кірмегенін тексере отырып, күтілетін нәтижеге қарсы чек жазасыз. Сіз сынақты іске қосуға тырысып жатырсыз, бірақ ол тіпті құрастырмайды, себебі сізде Login сыныбы жоқ. Сіз бұл жағдайды түзетесіз және жүйеге кіру үшін сол сыныптағы әдіспен бірге Login сыныбын және жүйеге кіргенін көру үшін пайдаланушының күйін тексеру үшін басқасын жасайсыз. Осы уақытқа дейін сіз осы сыныптың функционалдығын және бізге қажет әдісті енгізген жоқсыз. Осы сәтте сіз сынақты орындайсыз. Енді ол құрастырылады, бірақ бірден сәтсіздікке ұшырайды. Енді сіз codeқа оралып, сынақтан өту үшін функцияны орындаңыз. Біздің жағдайда бұл нәтиже алу керек дегенді білдіреді: «пайдаланушы жүйеге кірмеген». Сіз сынақты қайта орындайсыз, енді ол өтеді. Келесі сынаққа көшейік. Енді «Пайдаланушы жарамды логин мен құпия сөзді енгізсе, жүйеге кірді» деп аталатын тест жазу керек деп елестетіп көрейік. Сіз Login сыныбын жасайтын және пайдаланушы аты мен құпия сөз арқылы жүйеге кіру әрекетін жасайтын бірлік сынағын жазасыз. Бірлік сынағында сіз Login сыныбы пайдаланушы жүйеге кірді ме деген сұраққа иә деп жауап беруі керек деген мәлімдеме жазасыз. Сіз бұл жаңа сынақты орындайсыз және ол, әрине, сәтсіз аяқталады, себебі Login сыныбы әрқашан пайдаланушының жүйеге кірмегенін қайтарады. Сіз Кіру сыныбына ораласыз және пайдаланушы жүйеге кіргенін тексеру үшін кейбір codeты енгізесіз. Бұл жағдайда сіз бұл модульді қалай оқшаулау керектігін анықтауыңыз керек. Әзірге мұны істеудің ең оңай жолы - сынақта пайдаланған пайдаланушы аты мен құпия сөзді қатты codeтау және олар сәйкес келсе, «пайдаланушы жүйеге кірді» деген нәтижені қайтарыңыз. Сіз бұл өзгерісті жасайсыз, екі сынақты да орындайсыз және екеуі де өтеді. Соңғы қадамға көшейік: сіз генерацияланған codeты қарайсыз және оны қайта ұйымдастыру және жеңілдету жолын іздейсіз. Сонымен, TDD алгоритмі:

1. Тест құрылды.
2. Біз бұл сынақ үшін code жаздық.
3. Кодты қайта өңдеді.

қорытындылар

Мен осы кезеңде бірлік тестілеу және TDD туралы айтқым келгеннің бәрі осы. Шын мәнінде, code модульдерін оқшаулау әрекетімен байланысты көптеген қиындықтар бар, өйткені code өте күрделі және түсініксіз болуы мүмкін. Толық оқшауланған сыныптар өте аз. Оның орнына олардың тәуелділіктері бар, ал бұл тәуелділіктердің тәуелділіктері бар және т.б. Мұндай жағдайларды шешу үшін TDD ардагері тәуелді модульдердегі нысандарды ауыстыру арқылы жеке сыныптарды оқшаулауға көмектесетін мысқылдарды пайдаланады. Бұл мақала жай ғана шолу және бірлік сынағы мен TDD туралы біршама жеңілдетілген кіріспе, біз жалған модульдер және басқа TDD әдістері туралы егжей-тегжейлі қарастырмаймыз. Бұл идея сізге TDD және бірлік тестілеудің негізгі тұжырымдамалары мен принциптерін беру болып табылады, олар сізде қазір бар деп үміттенеді. Түпнұсқа - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/