Кіріспе

Бағдарламалық жасақтама тесттерін атау

Жүріс-тұрыс басшылықты дамыту (BDD) кодтың мінез-құлқын сипаттау үшін домендік тілді қолдана отырып, бағдарламалық жасақтама тесттерін атауды қамтиды. BDD домендік тілді (DSL) пайдалануды қамтиды, ол табиғи тіл құрылымдарын (мысалы, ағылшын тілі сияқты сөйлемдерді) қолдана отырып, мінез-құлықты және күтілетін нәтижелерді білдіреді. Жақтаушылар бұл бағдарламалық жасақтама жобасында әзірлеушілер, сапаны қамтамасыз ету сарапшылары және клиенттердің өкілдері арасындағы ынтымақтастықты ынталандырады деп мәлімдейді. Ол командаларды әңгімелесу және нақты мысалдарды пайдалану арқылы қолданады, бұл қолданбаның қалай жұмыс істеуі керектігі туралы ортақ түсінікті қалыптастыруға көмектеседі. BDD, әсіресе, мәселе кеңістігі күрделі болған кезде тиімді тәжірибе болып саналады. BDD тест басшылықты дамытудың (TDD) жетілдірілген түрі болып саналады. BDD TDD техникаларын домендік дизайн және объектіге бағытталған талдау мен дизайн идеяларымен біріктіреді, бағдарламалық жасақтаманы әзірлеу және басқару топтарын ортақ құралдармен және бағдарламалық жасақтаманы әзірлеуде бірлесіп жұмыс істеу үшін ортақ процестермен қамтамасыз етеді. 2009 жылдың қарашасында Лондонда өткен "Agile specifications, BDD and Testing eXchange" іс-шарасында Дэн Норт BDD-ді келесідей сипаттады: BDD – бұл екінші буын, сырттан ішке қарай, тартымдылыққа негізделген, көптеген мүдделі тараптарды, көп деңгейлі, жоғары автоматтандырылған, икемді әдістеме. Ол жақсы анықталған нәтижелермен өзара әрекеттесу циклын сипаттайды, нәтижесінде маңызды, жұмыс істейтін және тексерілген бағдарламалық жасақтама жеткізіледі.

Негізгі қағидалар

BDD бағдарламалық қамтамасыз етуді сынақтарды күтілетін мінез-құлық тұрғысынан атауды ұсынады. Әрбір пайдаланушы әңгімесі белгілі бір дәрежеде мынадай құрылымды ұстанғаны жөн:

Бұл формат Gherkin тілі деп аталады. Дегенмен, Gherkin термині Cucumber, JBehave, Lettuce, behave және Behat бағдарламалық құралдарына ғана тән.

Барлық жерде қолданылатын тіл ретінде спецификация

BDD домендік жобалаудан барлыққа ортақ тіл тұжырымдамасын қабылдайды. Аталған тілді команданың барлық мүшелері қолданады және дамытады, бұл бағдарламалық қамтамасының доменін талқылаудың ортақ құралы ретінде қызмет етеді. Бағдарламалық қамтамасты әзірлеудегі жиі кездесетін тәуекелдердің бірі – дамытушылар мен бизнес мүдделі тараптар арасындағы байланыс үзілуі. BDD жоба командасының мүшелері үшін қажетті мінез-құлықтың сипаттамасын барлыққа ортақ тіл ретінде пайдаланады. Сондықтан BDD мінез-құлық сипаттамасы үшін жартылай формалды тілді талап етеді: барлыққа ортақ тіл болу үшін белгілі бір формальдылық қажет. Бұл модель сондай-ақ қолжетімді BDD қолдайтын әртүрлі бағдарламалық құралдардың негізі болып табылады. Жоғарыда келтірілген мысал әзірленіп жатқан бағдарламалық жүйе үшін пайдаланушы туралы әңгіме құрады. Бұл пайдаланушы туралы әңгіме мүдделі тарапты, бизнес әсерін және бизнес құндылығын анықтайды. Сонымен қатар, әрқайсысы алдын ала шартты, оқиғаны қозғаушы факторды және күтілетін нәтижені қамтитын бірнеше сценарийлерді сипаттайды. Бұл бөліктердің әрқайсысы тілдің формалды бөлігімен нақты анықталады (мысалы, "Given" термині кілт сөз ретінде қарастырылуы мүмкін) және осылайша формалды бөліктерін түсінетін құралмен өңделуі мүмкін. BDD қолданбаларының көпшілігі мәтіндік DSL және сипаттама тәсілдерін пайдаланады. Дегенмен, интеграция сценарийлерін графикалық модельдеу тәжірибеде, мысалы, сынақ мақсатында да сәтті қолданылды.

Мамандандырылған құралдар

ТДД сияқты, БДД арнайы құралдарды қолдануды қажет етуі мүмкін. БДД, ТДД сияқты, сынақ кодын ғана емес, сонымен қатар мінез-құлқын адам оқи алатын тілде сипаттайтын құжатты да талап етеді. Бұл сынақтарды орындау үшін екі қадамдық процеске ие болуды білдіреді: сипаттамаларды оқу және талдау, содан кейін сынақ кодын оқып, орындалатын тиісті сынақ іске асырылуын табу. Осы процесс БДД-ні әзірлеушілер үшін көбірек еңбекке талап етеді. Жақтастары, құжаттардың адам оқи алатын түріне байланысты олардың құндылығы техникалық білімі аз аудиторияға да жетеді және осылайша талаптарды ("ерекшеліктерді") сипаттау үшін коммуникация құралы ретінде пайдалы бола алады деп санайды.

Құрал жасау қағидалары

Принцип бойынша, BDD қолдау құралы – бұл бағдарламалық жасақтаманы сынау жүйесі, TDD қолдайтын құралдарға ұқсас. Дегенмен, TDD құралдары сынақтарды нақтылау үшін рұқсат етілген нәрселерде еркін форматты болса, BDD құралдары барлық қатысушы тілдің анықтамасымен байланысты. Барлық қатысушы тіл бизнес-аналитиктерге мінез-құлық талаптарын осылайша құжаттауға мүмкіндік береді, оларды әзірлеушілер де түсіне алады. BDD қолдау құралының қағидасы – осы талаптарды құжаттарда тікелей орындалатын сынақтар жиынтығы ретінде жасау. Егер бұл техникалық құралға байланысты себептермен мүмкін болмаса, мінез-құлық талаптарын жазу стилі өзгертілуі керек немесе құрал ауыстырылуы керек. Мінез-құлық талаптарының нақты іске асырылуы құралдан құралға өзгеше болуы мүмкін, бірақ икемді әдістеме келесі жалпы процесті ұсынады:

Құрал спецификациялық құжатты оқиды. Құрал барлық қатысушы тілдің толыққанды ресми бөліктерін (мысалы, жоғарыдағы мысалдағы Given кілт сөзін) тікелей түсінеді. Осыған сүйене отырып, құрал әр сценарийді мағыналы бөліктерге бөледі. Әр сценарийдегі жеке бөлік пайдаланушы әңгімесіне арналған сынақтың параметріне айналады. Бұл бөлім бағдарламалық жасақтаманы әзірлеушілердің жобаға қатысты жұмысын қажет етеді. Содан кейін жүйе әр сценарийдің параметрлерімен сынақты орындайды. Дэн Норт BDD-ді қолдайтын бірнеше жүйелерді (соның ішінде JBehave және RBehave) жасады, олардың жұмысы пайдаланушы әңгімелерін жазу үшін оның ұсынған үлгісіне негізделген.