TDD жана бирдик тести деген эмне [которуу]

Бул макала The Complete Software Career Guide китебинин бөлүмдөрүнүн адаптациясы. Анын автору Джон Сонмез аны жазып, айрым бөлүмдөрүн өзүнүн веб-сайтына жайгаштырган.

Жаңы баштагандар үчүн кыскача глоссарий

Бирдикти тестирлөө же бирдикти тестирлөө - бул программанын баштапкы codeунун айрым модулдарынын тууралыгын текшерүүгө мүмкүндүк берүүчү программалоо процесси. Идея ар бир маанилүү эмес функция же ыкма үчүн тест жазуу болуп саналат. Регрессиялык тестирлөө бул баштапкы codeдун буга чейин текшерилген аймактарында каталарды табууга багытталган программалык камсыздоону сыноонун бардык түрлөрүнүн жалпы аталышы. Мындай каталар - программага өзгөртүүлөр киргизилгенден кийин, ишин уланта турган нерсе иштебей калганда - регрессиялык каталар деп аталат. Кызыл натыйжа, ийгorксиздик - тесттин ийгorксиздиги. Күтүлгөн натыйжа менен иш жүзүндөгү натыйжанын ортосундагы айырма. Жашыл натыйжа, өтүү - тесттин оң натыйжасы. Иш жүзүндөгү натыйжа алынгандан эч айырмаланbyte. *** Мен сүйүүдөн жек көрүү жана кайра кайра өтүп, Test Driven Development (TDD) жана бирдик тестирлөө менен абдан аралаш мамиледемин. Мен күйөрман болчумун жана ошол эле учурда муну жана башка "мыкты тажрыйбаларды" колдонууга шектенчү эмесмин. Менин мамилемдин себеби программалык камсыздоону иштеп чыгуу процесстеринде олуттуу көйгөй пайда болгондугуна негизделет: иштеп чыгуучулар, кээде менеджерлер айрым инструменттерди жана методологияларды "мыкты тажрыйбаларга" таандык болгону үчүн гана колдонушат. Аларды колдонуунун чыныгы себеби белгисиз бойдон калууда. Бир күнү мен белгилүү бир долбоордун үстүндө иштей баштадым жана бул процессте мен көптөгөн бирдик сыноолорунда камтылган codeду өзгөртөбүз деп кабарлашты. Тамаша эмес, алардын 3000дейи бар болчу.Бул адатта жакшы жышаан, иштеп чыгуучулар алдыңкы методологияларды колдонуп жатканынын белгиси. Бул ыкма менен code көбүнчө структуралаштырылган жана ал жакшы ойлонулган архитектурага негизделген. Бир сөз менен айтканда, тесттердин болушу мени кубандырды, анткени бул менин программисттердин насаатчысы катары жумушумду жеңилдетти. Бизде буга чейин бирдик тесттери болгондуктан, мен аларды колдоо үчүн иштеп чыгуу тобун бириктирип, өзүбүздүн codeубузду жаза башташым керек болчу. Мен IDE (интегралдык өнүктүрүү чөйрөсү) ачып, долбоорду жүктөдүм. Бул чоң долбоор болду! Мен "бирдик тесттери" деген папканы таптым. "Сонун" деп ойлодум мен. - Келгиле, аны ишке киргизели, эмне болорун көрөбүз. Бул бир нече мүнөттү талап кылды жана мени таң калтырганы, бардык сыноолор өттү, баары жашыл болду ( "жашыл" - тесттин оң натыйжасы. Код күтүлгөндөй иштеп жатканын билдирет. Кызыл "иштебегенди" же ийгorксиздикти билдирет, анан code туура иштебей калган учур бар - котормочунун эскертүүсү ). Алардын баары сынактан өтүштү. Ошол учурда ичимдеги скептик ойгонду. Кантип эле, үч миң бирдик тесттер, алар бир эле учурда алардын баарын алып, оң натыйжа берди? Узак практикамда codeдо бир дагы терс бирдик сынагы жок долбоордо иштей баштаганымды эстей албадым. Эмне кылыш керек? Кол менен текшериңиз! ChY эң ачык эмес, кокус бир тестти тандап алды, бирок анын эмнени текшерип жатканы дароо айкын болду. Бирок аны иштеп жатып, мен акылга сыйбаган нерсени байкадым: тестте күтүлгөн натыйжа менен эч кандай салыштыруулар болгон эмес (тастыктоодо)! Башкача айтканда, чындыгында эч нерсе текшерилген эмес ! Тестте белгилүү кадамдар бар болчу, алар аткарылды, бирок тесттин аягында ал иш жүзүндөгү жана күтүлгөн натыйжаларды салыштыруу керек, текшерүү болгон жок. «Тест» эч нерсе сынаган жок. Мен дагы бир тестти ачтым. Андан да жакшысы: натыйжасы менен салыштыруу операторуна комментарий берилди. Мыкты! Бул тесттен өтүүнүн эң сонун жолу, жөн гана анын ишке ашпай калышына себеп болгон codeду комментарийлеңиз. Мен дагы бир тестти текшердим, анан дагы бир... Алардын эч кимиси эч нерсе текшерген жок. Үч миң сыноо, алардын баары таптакыр жараксыз. Бирдик тесттерин жазуу менен бирдикти тестирлөө менен тестирлөөгө негизделген өнүгүүнү (TDD) түшүнүүнүн ортосунда чоң айырма бар.

Бирдикти сыноо деген эмне?

Бирдикти тестирлөөнүн негизги идеясы - codeдун эң кичинекей "бирдигин" сынаган тесттерди жазуу. Бирдиктин тесттери, адатта, колдонмонун баштапкы codeу менен бир эле программалоо тorнде жазылат. Алар бул codeду сыноо үчүн түз түзүлөт. Башкача айтканда, бирдик тесттери башка codeдун тууралыгын текшерген code. Мен "тест" деген сөздү контекстте абдан эркин колдоном, анткени бирдик тесттери кандайдыр бир мааниде тест эмес. Алар эч нерсени башынан өткөрбөйт. Айтайын дегеним, сиз бирдик сынагын иштеткениңизде, адатта, кээ бир code иштебей турганын таппайсыз. Сиз муну тестти жазып жатканда табасыз, анткени тест жашыл түскө айланганга чейин codeду өзгөртөсүз. Ооба, code кийинчерээк өзгөрүп, андан кийин сынагыңыз ишке ашпай калышы мүмкүн. Демек, бул жагынан алганда, бирдик тест регрессиялык тест болуп саналат. Бирдик сынагы кадимки тестке окшош эмес, анда сиз аткара турган бир нече кадамдарыңыз бар жана программалык камсыздоонун туура же иштебегенин көрөсүз. Бирдик сынагын жазуу процессинде, сиз codeдун эмне кылышы керек экенин же жокпу, билесиз жана тесттен өткөнгө чейин codeду өзгөртөсүз. Эмне үчүн бирдик сынагын жазып, анын өткөнүн текшерип көрбөйсүзбү? Эгер сиз бул жөнүндө ойлонуп көрсөңүз, анда бирдик тесттери өтө төмөн деңгээлдеги кээ бир code модулдары үчүн кандайдыр бир абсолюттук талаптарга айланат. Сиз бирдик сынагын абсолюттук спецификация деп ойлосоңуз болот . Бирдиктин тести ушул шарттарда, ушул өзгөчө киргизүүлөрдүн топтому менен, codeдун ушул бирдигинен алуу керек болгон жыйынтык бар экенин аныктайт. Чыныгы бирдикти текшерүү codeдун эң кичинекей когеренттүү бирдигин аныктайт, ал көпчүлүк программалоо тилдеринде - жок дегенде an objectиге багытталган - класс болуп саналат.

Кээде бирдикти тестирлөө эмне деп аталат?

Бирдикти тестирлөө көбүнчө интеграциялык тестирлөө менен чаташтырылат. Кээ бир "бирдик тесттери" бирден ашык классты сынайт же codeдун чоң бирдиктерин сынайт. Көптөгөн иштеп чыгуучулар бирдик тесттерин жазышат деп ырасташат, бирок чындыгында алар төмөнкү деңгээлдеги ак кутуча тесттерин жазышат. Бул жигиттер менен урушпагыла. Болгону, алар чындыгында интеграциялык тесттерди жазышат жана чыныгы бирдик тесттери codeдун эң кичинекей бирдигин башка бөлүктөрдөн бөлүп текшерет. Көбүнчө бирдик тести деп аталган дагы бир нерсе - бул күтүлгөн мааниге каршы текшерүүсүз бирдик тесттери. Башкача айтканда, иш жүзүндө эч нерсени сынабаган бирдик тесттери. Ар кандай тест, бирдиктүү же жок, кандайдыр бир текшерүүнү камтышы керек - биз аны иш жүзүндөгү натыйжаны күтүлгөн натыйжага каршы текшерүү деп атайбыз. Дал ушул элдешүү сынактан өткөнүн же өтпөй калганын аныктайт. Дайыма өтүп кеткен сынак пайдасыз. Ар дайым ийгorксиз болгон сыноо пайдасыз.

Бирдикти сыноонун мааниси

Эмне үчүн мен бирдикти тестирлөө ышкыбозумун? Башка codeдон обочолонгон эң кичинекей блокту эмес, codeдун чоңураак бөлүгүн, "бирдикти тестирлөө" тестирлөөнү камтыган жалпыланган тестирлөө эмне үчүн зыяндуу? Эгерде менин кээ бир тесттерим алынган жана күтүлгөн натыйжаларды салыштырбаса, кандай көйгөй бар? Жок дегенде алар codeду аткарышат. Мен түшүндүрүп берүүгө аракет кылам. Бирдикти тестирлөөнүн эки негизги себеби бар. Биринчиси - code дизайнын жакшыртуу. Бирдикти тестирлөө чындыгында тестирлөө эмес деп айтканымды эстейсизби? Туура бирдик тесттерин жазганда, сиз өзүңүздү codeдун эң кичинекей бирдигин бөлүп алууга мажбурлайсыз. Бул аракеттер сизди codeдун түзүмүндөгү көйгөйлөрдү табууга алып келет. Сизге сыноо классын бөлүп алуу жана анын көз карандылыктарын камтыбоо абдан кыйын болушу мүмкүн жана бул сиздин codeуңуз өтө тыгыз байланышта экенин түшүнүүгө түрткү бериши мүмкүн. Сиз сынап жаткан негизги функциялар бир нече модулдарды камтыганын байкасаңыз, бул сиздин codeуңуз жетиштүү ырааттуу эмес деген ойго алып келет. Сиз бирдик сынагын жазуу үчүн отурганда, codeу эмне кылышы керек экенин түшүнбөй калганыңызды күтүлбөгөн жерден байкап калышыңыз мүмкүн (жана мага ишениңиз, ошондой болот!). Демек, сиз ага бирдик сынагын жаза албайсыз. Жана, албетте, сиз codeду ишке ашырууда чыныгы мүчүлүштүктөрдү таба аласыз, анткени бирдик тести сизди кутудан тышкары ойлонууга жана сиз ойлобогон киргизүүлөрдүн ар кандай топтомун сыноого мажбурлайт. Эгер сиз бирдик тесттерин түзүүдө "codeдун эң кичинекей бирдигин башкалардан бөлүп сынап көрүңүз" эрежесин так сактасаңыз, анда сиз ошол code менен жана ал модулдардын дизайны менен ар кандай көйгөйлөрдү таба аласыз. Программалык камсыздоону иштеп чыгуунун жашоо циклинде бирдикти тестирлөө тестирлөө ишине караганда баалоо иш-аракети болуп саналат. Бирдикти тестирлөөнүн экинчи негизги максаты программалык камсыздоонун жүрүм-турумунун төмөнкү деңгээлдеги спецификациясы катары иштей ала турган регрессиялык тесттердин автоматташтырылган комплексин түзүү болуп саналат. Бул эмнени билдирет? Камыр жууруганда сынбайсыз. Бул көз караштан алганда, бирдик тесттер тесттер, тагыраак айтканда, регрессиялык тесттер. Бирок, бирдикти тестирлөөнүн максаты жөн гана регрессиялык тесттерди куруу эмес. Иш жүзүндө, бирдик тесттери сейрек регрессияларды кармайт, анткени сиз сынап жаткан code бирдигине өзгөртүү дээрлик дайыма бирдик сынагынын өзүнө өзгөртүүлөрдү камтыйт. Регрессиялык тестирлөө жогорку деңгээлде, code "кара куту" катары текшерилгенде алда канча эффективдүү болот, анткени бул деңгээлде codeдун ички түзүмүн өзгөртүүгө болот, ал эми тышкы жүрүм-турум ошол эле бойдон калуусу күтүлүүдө. Бирдиктин тесттери өз кезегинде ички структураны текшерет, ошондо ал структура өзгөргөндө, бирдик сыноолору ийгorксиз болуп калbyte. Алар жараксыз болуп калат жана азыр өзгөртүп, ыргытып же кайра жазуу керек. Сиз азыр көптөгөн ардагер программалык камсыздоону иштеп чыгуучуларга караганда бирдикти тестирлөөнүн чыныгы максаты жөнүндө көбүрөөк билесиз.

Test Driven Development (TDD) деген эмне?

Программалык камсыздоону иштеп чыгуу процессинде жакшы спецификация алтынга барабар. TDD ыкмасы - бул кандайдыр бир codeду жазуудан мурун, сиз адегенде спецификация катары кызмат кыла турган тест жазасыз, башкача айтканда, code эмне кылышы керектигин аныктайт. Бул өтө күчтүү программалык камсыздоону иштеп чыгуу концепциясы, бирок ал көп учурда туура эмес колдонулат. Адатта, тестирлөөгө негизделген иштеп чыгуу колдонмо codeун түзүүгө жетекчorк кылуу үчүн бирдик тесттерин колдонууну билдирет. Бирок, чындыгында, бул ыкма ар кандай деңгээлде колдонулушу мүмкүн. Бирок, бул макалада биз колдонмобуз үчүн бирдик тестин колдонуп жатабыз деп ойлойбуз. TDD мамилеси бардыгын өз нугуна бурат жана адегенде code жазып, анан ошол codeду сынап көрүү үчүн бирдик тесттерин жазуунун ордуна, сиз адегенде бирдик сынагын жазып, андан кийин ал тестти жашыл кылуу үчүн code жазасыз. Ошентип, бирдикти тестирлөө codeду иштеп чыгууну "дистейт". Бул процесс кайра-кайра кайталанат. Сиз codeдун эмне кылышы керек экендигин аныктоочу дагы бир тест жазасыз. Андан кийин сиз тесттин ийгorктүү аякташын камсыз кылуу үчүн codeду жазып, өзгөртөсүз. Жашыл натыйжага ээ болгондон кийин, сиз codeду рефакторингди баштайсыз, башкача айтканда, аны кыскараак кылуу үчүн аны рефакторинг же тазалоо. Процесстердин бул чынжырчасы көбүнчө "Кызыл-Жашыл-Рефакторинг" деп аталат, анткени адегенде бирдик сынагы ийгorксиз болуп калат (кызыл), андан кийин code тестке ыңгайлашуу үчүн жазылат, анын ийгorктүү өткөнүнө ынануу (жашыл) жана акырында code оптималдаштырылган ( рефакторинг).

TDD максаты эмне?

Тестке негизделген иштеп чыгуу (TDD), бирдикти тестирлөө сыяктуу, туура эмес колдонулушу мүмкүн. Жасаган ишиңизди "TDD" деп атоого, ал тургай, эмне үчүн мындай кылып жатканыңызды түшүнбөстөн, практиканы аткаруу абдан оңой. TDDнин эң чоң баалуулугу - бул сапат спецификацияларын чыгаруу үчүн тесттер өткөрүлөт. TDD - бул codeдоо жазылганга чейин автоматтык түрдө текшериле турган так спецификацияларды жазуу практикасы. Тесттер эң жакшы спецификациялар, анткени алар калп айтпайт. Алар сизге эки жумалык кыйноодон кийин "мен такыр айткан эмесмин" деген code менен айтышпайт. Тесттер, туура жазылганда, же ийгorктүү же өтпөй калат. Тесттер белгилүү бир шарттарда эмне болушу керектигин так көрсөтүп турат. Ошентип, TDD максаты - биз аны ишке ашырууну баштоодон мурун, эмнени ишке ашыруу керек экендиги жөнүндө толук түшүнүк берүү. Эгер сиз TDD менен иштеп жатсаңыз жана тест эмнени сынашы керек экенин түшүнө албасаңыз, анда көбүрөөк суроолорду беришиңиз керек. TDD дагы бир маанилүү ролу codeду сактоо жана оптималдаштыруу болуп саналат. Кодду тейлөө кымбатка турат. Мен көбүнчө эң мыкты программист кандайдыр бир маселени чечүүчү эң кыска codeду жазган адам деп тамашалайм. Же бул көйгөйдү чечүүнүн кереги жок экенин далилдеген адам жана ошону менен codeду толугу менен жок кылат, анткени дал ушул программист каталардын санын кыскартуунун жана тиркемени тейлөөгө кеткен чыгымдарды азайтуунун туура жолун тапкан. TDD колдонуу менен, сиз эч кандай керексиз codeду жазбаганыңызга толук ишене аласыз, анткени сиз тесттерден өтүү үчүн гана code жазасыз. YAGNI деп аталган программалык камсыздоону иштеп чыгуу принциби бар (бул сизге кереги жок). TDD YAGNI алдын алат.

Typical Test Driven Development (TDD) Workflow

Жалаң академиялык көз караштан TDD маанисин түшүнүү кыйын. Ошентип, келгиле, TDD сессиясынын мисалын карап көрөлү. Үстөлүңүзгө отуруп алып, колдонуучуга тиркемеге кирип, сырсөзүн унутуп калган учурда өзгөртүүгө мүмкүндүк берген функциянын жогорку деңгээлдеги дизайны болот деп ойлогон нерсени тез элестетип көрүңүз. Сиз кирүү процессинин бардык логикасын чече турган классты түзүп, логин функциясын биринчи ишке ашыруудан баштоону чечесиз. Сиз сүйүктүү редакторуңузду ачып, "Бош кирүү колдонуучунун кирүүсүнө жол бербейт" деп аталган бирдик сынагын түзөсүз. Сиз адегенде Login классынын (сиз али түзө элек) мисалын түзгөн бирдиктин сыноо codeун жазасыз. Андан кийин сиз бош колдонуучу атын жана паролду өткөргөн Login классындагы методду чакыруу үчүн code жазасыз. Акыр-аягы, сиз күтүлгөн натыйжага каршы чек жазасыз, бош логини бар колдонуучу чындыгында кирбегенин текшерет. Сиз тест жүргүзүүгө аракет кылып жатасыз, бирок ал түзүлбөйт, анткени сизде Login классы жок. Сиз бул абалды оңдоп, Кирүү классын түзөсүз жана ошол класстагы ыкма менен кирүү үчүн, ал эми башкасы колдонуучунун статусун текшерип, алар киргендигин текшересиз. Азырынча сиз бул класстын функционалдуулугун жана бизге керектүү ыкманы ишке ашыра элексиз. Бул учурда сиз тестти өткөрөсүз. Азыр ал түзүлөт, бирок дароо иштебей калат. Эми сиз codeго кайтып келип, тесттен өтүү үчүн функцияны ишке ашырасыз. Биздин учурда, бул натыйжаны алышыбыз керек дегенди билдирет: "колдонуучу кирген эмес." Сиз тестти кайра тапшырасыз жана ал өтүп жатат. Келгиле, кийинки тестке өтөбүз. Эми сиз "Колдонуучу жарактуу логин жана паролду киргизсе, кирди" деген тест жазуу керек деп элестетип көрөлү. Сиз Login классын түзүүчү жана колдонуучу аты жана сырсөз менен кирүүгө аракет кылган бирдик тестин жазасыз. Бирдик сынагында сиз Login классы колдонуучу киргенби деген суроого ооба деп жооп бериши керек деген билдирүү жазасыз. Сиз бул жаңы тестти аткарасыз жана, албетте, ал ишке ашпай калат, анткени сиздин Login классыңыз дайыма колдонуучу кирбегенин кайтарып берет. Сиз Кирүү классыңызга кайтып, колдонуучунун киргенин текшерүү үчүн кандайдыр бир codeду ишке ашырасыз. Бул учурда, сиз бул модулду кантип изоляциялоону чечишиңиз керек болот. Азырынча муну жасоонун эң оңой жолу – тестиңизде колдонгон колдонуучунун атын жана паролду катуу codeдоо жана эгер алар дал келсе, анда "колдонуучу кирди" деген жыйынтыкты кайтарыңыз. Сиз бул өзгөртүүнү киргизип, эки сыноону тең өткөрөсүз жана экөө тең ийгorктүү өтүшөт. Келгиле, акыркы кадамга өтөбүз: сиз түзүлгөн codeду карап, аны кайра уюштуруунун жана жөнөкөйлөштүрүүнүн жолун издейсиз. Ошентип, TDD алгоритми:

1. Тест түздү.
2. Бул сыноо үчүн code жаздык.
3. Код рефакторацияланды.

корутундулар

Бул этапта бирдик тестирлөө жана TDD жөнүндө айткым келгендин баары ушул. Чынында, code модулдарын обочолонтуу аракети менен байланышкан көптөгөн кыйынчылыктар бар, анткени code өтө татаал жана чаташкан болушу мүмкүн. Абдан аз класстар толугу менен обочолонуп бар. Анын ордуна, алардын көз карандылыктары бар, ал эми ошол көз карандылыктардын көз карандылыгы бар ж.б.у.с. Мындай жагдайларды чечүү үчүн, TDD ардагери көз каранды модулдардагы an objectтерди алмаштыруу менен айрым класстарды изоляциялоого жардам берген шылдыңдарды колдонот. Бул макала жөн гана карап чыгуу жана бирдикти тестирлөө жана TDD үчүн бир аз жөнөкөйлөштүрүлгөн киришүү, биз жасалма модулдар жана башка TDD ыкмалары жөнүндө майда-чүйдөсүнө чейин кирбейбиз. Идея сизге TDD жана бирдикти тестирлөөнүн негизги түшүнүктөрүн жана принциптерин берүү, сизде азыр бар деп үмүттөнөбүз. Түпнуска - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/