Мінез-құлыққа негізделген даму - Behavior-driven development - Wikipedia

Бағдарламалық жасақтама жасау
Негізгі қызмет
Парадигмалар мен модельдер
Әдістемелер және шеңберлер
Қолдау пәндері
Тәжірибелер
Құралдар
Стандарттар және білім органдары
Глоссарийлер
Контурлар

Жылы бағдарламалық жасақтама, мінез-құлыққа негізделген даму (BDD) болып табылады Бағдарламалық жасақтаманы жылдам әзірлеу бағдарламалық қамтамасыз ету жобасының әзірлеушілері, QA және техникалық емес немесе бизнес қатысушылары арасындағы ынтымақтастықты ынталандыратын процесс.[1][2][3] Бұл команданы қосымшаның өзін қалай ұстау керектігі туралы жалпы түсінікті рәсімдеу үшін әңгімелесу мен нақты мысалдарды қолдануға шақырады.[4] Ол пайда болды тестке негізделген даму (TDD).[1][2][5][6][бұлыңғыр ][7] Мінез-құлыққа негізделген даму TDD-дің жалпы әдістері мен принциптерін идеялармен үйлестіреді доменге негізделген дизайн және объектіге бағытталған талдау және жобалау бағдарламалық жасақтаманы әзірлеу және басқару топтарын ортақ құралдармен қамтамасыз ету және бағдарламалық жасақтаманы әзірлеуде бірлесіп жұмыс істеу үшін ортақ процесс.[2][7]

BDD негізінен бағдарламалық жасақтаманы іскерлік мүдделермен және техникалық түсініктермен басқаруға болатындығы туралы идея болғанымен, BDD тәжірибесі әзірлеу процесін қолдау үшін арнайы бағдарламалық жасақтама құралдарын қолдануды болжайды.[5] Бұл құралдар көбінесе BDD жобаларында пайдалану үшін арнайы жасалынғанымен, оларды тестілеуге негізделген дамуды қолдайтын құрал-саймандардың мамандандырылған түрлері ретінде қарастыруға болады. Құралдар автоматтандыруды қосуға қызмет етеді барлық жерде қолданылатын тіл бұл BDD-нің басты тақырыбы.

BDD көбінесе қарапайым қолдану арқылы жеңілдетіледі арнайы домен (DSL) мінез-құлықты және күтілетін нәтижелерді көрсете алатын табиғи тілдегі конструкцияларды (мысалы, ағылшын тіліне ұқсас сөйлемдер) пайдалану. Тесттік сценарийлер әр түрлі талғампаздық деңгейіне ие DSL-дің танымал қосымшасы болды. BDD тиімді техникалық практика болып саналады, әсіресе шешілетін бизнес проблемасының «проблемалық кеңістігі» күрделі болған жағдайда.[8]

Тарих

Мінез-құлыққа негізделген даму - бұл кеңейту тестке негізделген даму:[9] қарапайым, доменге арналған сценарий тілін (DSL) пайдаланатын әзірлеу. Бұл DSL-дер құрылымдық табиғи тілдегі мәлімдемелерді орындалатын тесттерге түрлендіреді. Нәтижесінде берілген функцияны қабылдау критерийлерімен және осы функционалдылықты тексеру үшін қолданылатын тесттермен тығыз байланыс пайда болады. Осылайша, бұл TDD тестілеуінің табиғи жалғасы.

BDD:

  • Процесті неден бастау керек
  • Нені сынап, нені сынамау керек
  • Бір демде қанша сынап көру керек
  • Тесттерді қалай атауға болады
  • Тесттің неге сәтсіздікке ұшырағанын қалай түсінуге болады

Оның негізінде BDD көзқарасты қайта қарау туралы блокты сынау және қабылдау тесті әрине туындайтын мәселелерден аулақ болу үшін. Мысалы, BDD бірлік сынақ атаулары шартты етістіктен басталатын тұтас сөйлемдер (мысалы, ағылшын тілінде «should») және іскерлік мәні бойынша жазылуы керек деп ұсынады. Қабылдау тестілері а-ның стандартты икемді шеңберін қолдану арқылы жазылуы керек пайдаланушы тарихы: «Мен [рөл / актер / мүдделі тарап] бола отырып, [пайда / мүмкіндік беретін [ерекшелік / мүмкіндік] алғым келеді». Қабылдау критерийлері сценарий бойынша жазылып, сабақтарда орындалуы керек: [Оқиға »болған кезде [бастапқы контекст] берілген, содан кейін [кейбір нәтижелерді қамтамасыз ету] .

Осы сәттен бастап көптеген адамдар бірнеше жыл ішінде BDD жақтауларын дамытты, ақырында оны әзірлеушілер үшін байланыс және ынтымақтастық шеңберінде құрды, QA бағдарламалық жасақтама жобасының техникалық емес немесе іскери қатысушылары.[10] 2009 жылдың қараша айында Лондон, Дэн Нортта «Agile спецификациялары, BDD және Testing eXchange» барысында[11] BDD келесі сипаттамасын берді:

BDD - екінші буын, сырттан тарту, тартуға негізделген, көп мүдделі, көп масштабты, жоғары автоматика, икемді әдіснамалар. Бұл нақты анықталған нәтижелермен өзара әрекеттесу циклын сипаттайды, нәтижесінде жұмыс істейтін, тексерілген бағдарламалық жасақтама жеткізіледі.

Диз Нортпен 2013 жылы ГОТО конференциясында Лиз Кеогпен сұхбат барысында[12] BDD анықтайды:

Бұл қосымшаның өзін қалай ұстайтыны туралы сөйлесу үшін мысалдарды қолдану ... және сол мысалдар туралы сұхбаттасу.[13]

Дэн Норт BDD шеңберін құрды, Дж, содан кейін Ruby-ге арналған RBehave деп аталатын әңгіме деңгейіндегі BDD жақтауы[14] кейінірек интеграцияланған RSpec жоба.[15] Ол сонымен қатар Дэвид Челимскиймен, Аслак Хеллесоймен және басқалармен бірге RSpec-ті дамытып, «RSpec кітабы: RSpec, қияр және достарымен мінез-құлықты дамыту» атты еңбектер жазды. RSpec-тегі алғашқы әңгімеге негізделген құрылым кейінірек ауыстырылды Қияр негізінен дамыған Аслак Хеллесой. Капибара, қиярды тестілеу шеңберінің бөлігі болып табылатын, тестілеуді автоматтандыруға арналған веб-бағдарламалық жасақтаманың бірі болып табылады.

BDD принциптері

Тестке негізделген әзірлеу - бұл бағдарламалық жасақтаманы әзірлеу әдістемесі, онда бағдарламалық жасақтаманың әр бірлігі үшін бағдарламалық жасақтама:

  • блок үшін сынақ жиынтығын анықтаңыз бірінші;
  • тестілерді сәтсіз ету;
  • содан кейін қондырғыны іске асырыңыз;
  • сайып келгенде, блоктың іске асырылуы тестілердің ойдағыдай болатындығын тексеріңіз.

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

Мінез-құлыққа негізделген даму кез-келген бағдарламалық жасақтаманың сынақтары блоктың қажетті мінез-құлқы тұрғысынан көрсетілуі керек екенін анықтайды.[5][7][1] Қарыз алу жылдам бағдарламалық қамтамасыздандыру «қалаған мінез-құлық» бұл жағдайда бизнес белгілейтін талаптардан тұрады, яғни оған ие болатын мінез-құлық іскерлік мәні салынып жатқан бағдарламалық жасақтаманы қай компанияға тапсырса да.[5][1] BDD тәжірибесінде бұл BDD «сырттан» әрекет деп аталады.[16]

Мінез-құлық сипаттамалары

Осы іргелі таңдаудың артынан BDD жасаған екінші таңдау қатысты Қалай қажетті мінез-құлық көрсетілуі керек. Бұл салада BDD мінез-құлық спецификациясының жартылай форматын пайдалануды таңдайды, ол пайдаланушы тарихының сипаттамаларынан өрістен алынған. объектіге бағытталған талдау және жобалау. The сценарий осы форматтың аспектісі қолдану ретінде қарастырылуы мүмкін Логика бағдарламалық жасақтаманы қолданатын мінез-құлық сипаттамаларына Домен тілі жағдай туралы.

BDD бизнес-талдаушылар мен әзірлеушілердің осы салада бірлесіп жұмыс істеуі және мінез-құлықты осыған байланысты көрсетуі керектігін анықтайды пайдаланушы туралы әңгімелер, олардың әрқайсысы арнайы құжатта нақты жазылған.[1][16] Әрқайсысы Пайдаланушы тарихы қандай да бір түрде келесі құрылымды ұстануы керек:[5][16]

Тақырып
Айқын тақырып.
Повесть
Келесі құрылымдағы қысқаша кіріспе бөлімі:
  • Сияқты: ерекшелікке ие болатын адам немесе рөл;
  • Мен ... алғым келеді: ерекшелігі;
  • сондай-ақ: мүмкіндіктің пайдасы немесе мәні.
Қабылдау критерийлері
Әр нақты сипаттама сценарий баяндаудың келесі құрылымы:
  • Берілген: сценарийдің басында, бір немесе бірнеше тармақта бастапқы контекст;
  • Қашан: сценарийді іске қосатын оқиға;
  • Содан кейін: бір немесе бірнеше тармақтарда күтілетін нәтиже.

BDD-ге нақты талаптар қойылмайды Қалай мыналар пайдаланушы туралы әңгімелер жазылуы керек, бірақ BDD-ді қолданатын әр топ қарапайым, стандартты форматты жазу үшін стандартты форматты ойлап табуды талап етеді. пайдаланушы туралы әңгімелер ол жоғарыда аталған элементтерді қамтиды.[5][16] Алайда, 2007 жылы Дэн Норт мәтіндік формат шаблонын ұсынды, ол әр түрлі BDD бағдарламалық құралдарында кең іздестірді.[16] Осы форматтың өте қысқа мысалы келесідей болуы мүмкін:

Тақырып: Қайтару және айырбастау түгендеуге барады.Сияқты дүкен иесі,Мен ... алғым келеді заттарды қайтарған немесе айырбастаған кезде оларды запасқа қайта қосу;сондай-ақ Мен түгендеуді бақылай аламын.1-сценарий: Қайтаруға қайтарылған заттарды тізімдемеге қосу керек.Берілген тапсырыс беруші бұрын менден қара жемпір сатып алғанжәне Менде үш қара жемпір бар,қашан олар қара жемпірді қайтару үшін қайтарады,содан кейін Түгендеуімде төрт қара жемпір болуы керек.Сценарий 2: Айырбасталған заттар тізімдемеге қайтарылуы керек.Берілген тапсырыс беруші бұрын менен көк түсті киім сатып алғанжәне Түгендеуде менің көк түсті екі киімім баржәне түгендеудегі үш қара киім,қашан олар көк киімді қара киімге айырбастайды,содан кейін Түгендеуімде үш көк түсті киім болу керекжәне түгендеудегі екі қара киім.

The сценарийлер өзара іс-қимыл жүзеге асырылатын интерфейс элементтеріне сілтеме жасамай, іскери тілде - императивті емес, декларативті түрде өте ыңғайлы.[17]

Бұл формат жоғарыда келтірілген мысалға ұқсас синтаксиске ие болған геркин тілі деп аталады. Термин Геркин, дегенмен, нақты Қияр, JBehave, салат жапырағы,[18] өзін ұстау және Бехат бағдарламалық құралдар.[19][20][21][22]

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

Мінез-құлыққа негізделген даму барлық жерде қолданылатын тіл бастап доменге негізделген дизайн.[5][7] Барлық жерде қолданылатын тіл - бұл бағдарламалық жасақтама жасаушылар тобының барлық мүшелері - бағдарламалық жасақтама жасаушылар да, техникалық емес қызметкерлер де ортақ (жартылай) ресми тіл.[23] Қарастырылып отырған тілді барлық топ мүшелері қарастырылып отырған бағдарламалық жасақтама доменін талқылаудың жалпы құралы ретінде қолданады және дамытады.[23] Осылайша, BDD бағдарламалық жасақтама жобасындағы барлық түрлі рөлдер арасындағы байланыс құралы болады.[5][24]

Бағдарламалық жасақтаманы дамытудағы жалпы тәуекелге Әзірлеушілер мен Іске қатысушы тараптар арасындағы байланыстың бұзылуы жатады.[25] BDD қалаған мінез-құлық сипаттамасын жоба мүшелері үшін барлық жерде қолданылатын тіл ретінде қолданады. BDD мінез-құлықты нақтылау үшін жартылай формальды тілді талап ететін себебі: кейбір формальдылық барлық жерде қолданылатын тіл болып табылады.[5] Сонымен қатар, барлық жерде осындай тілге ие болу сипаттамалардың домендік моделін жасайды, осылайша спецификациялар формальды түрде негізделуі мүмкін.[26] Бұл модель BDD қолдайтын әр түрлі бағдарламалық жасақтама құралдарының негізі болып табылады.

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

BDD қосымшаларының көпшілігі мәтінге негізделген DSL және спецификация тәсілдерін қолданады. Алайда интеграция сценарийлерін графикалық модельдеу тәжірибеде сәтті қолданылды, мысалы, тестілеу мақсатында. [27]

Мамандандырылған құрал-саймандарды қолдау

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

Құралдар принциптері

Негізінен BDD қолдау құралы - бұл TDD қолдайтын құралдар сияқты бағдарламалық жасақтама үшін тестілеу жүйесі. Алайда, егер TDD құралдары тестілерді көрсетуге рұқсат етілген форматта еркін болса, BDD құралдары бұрын талқыланған барлық жерде қолданылатын тілдің анықтамасымен байланысты.

Талқылауға сәйкес, барлық жерде қолданылатын тіл бизнес-талдаушыларға мінез-құлық талаптарын әзірлеушілер түсінетін етіп жазуға мүмкіндік береді. BDD қолдау құралдарының принципі - дәл осы талаптарды тестілер жинағы сияқты тікелей орындалатын етіп жасау. Егер бұл техникалық сипаттаманы орындауға мүмкіндік беретін техникалық құралға байланысты себептерге байланысты қол жеткізілмесе, онда мінез-құлық талаптарын жазу стилін өзгерту керек немесе құралды өзгерту керек.[28] Мінез-құлық талаптарының нақты орындалуы әр құралға байланысты өзгереді, бірақ ептілік практикасы келесі жалпы процесті ұсынды:

  • Аспап спецификациялық құжатты оқиды.
  • Құрал барлық жерде қолданылатын тілдің формальды бөліктерін тікелей түсінеді (мысалы Берілген жоғарыдағы мысалдағы кілт сөз). Осыған сүйене отырып, құрал әр сценарийді мағыналы сөйлемдерге бөледі.
  • Сценарийдегі әрбір жеке тармақ пайдаланушы тарихын тексеру үшін қандай-да бір параметрге айналады. Бұл бөлім бағдарламалық жасақтама жасаушылардың арнайы жобалық жұмысын қажет етеді.
  • Содан кейін рамка әр сценарий үшін осы сценарийдің параметрлерімен бірге тест жасайды.

Дэн Норт BDD-ді қолдайтын бірқатар құрылымдар жасады (соның ішінде JBehave және Ребек ), оның жұмысы ол қолданушы туралы әңгімелерді жазу үшін ұсынған шаблонға негізделген.[5] Бұл құралдар пайдалану жағдайлары үшін мәтіндік сипаттаманы қолданады және бірнеше басқа құралдар (мысалы, CBehave) осыған сәйкес келеді. Алайда, бұл формат қажет емес, сондықтан басқа форматтарды қолданатын басқа құралдар бар. Мысалға, Фитнес (айналасында салынған шешім кестелері ), сонымен қатар BDD шығаруға қолданылған.[29]

Құралдар мысалдары

Қазіргі уақытта жобаларда әртүрлі платформалар мен бағдарламалау тілдеріне арналған BDD бағдарламалық жасақтамасының бірнеше түрлі мысалдары бар.

Мүмкін ең танымал JBehave болуы мүмкін, оны Дэн Норт, Элизабет Кеог және тағы басқалар жасаған.[30] Төменде сол жобадан алынған мысал келтірілген:[20]

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

Берілген 5-тен 5-ке дейінгі ойынҚашан Мен ұяшықты (3, 2) ауыстырып қосамынСодан кейін тор ................. X ....... сияқты көрінуі керекҚашан Мен ұяшықты (3, 1) ауыстырып қосамынСодан кейін тор ................. Х .... Х .. сияқты көрінуі керек.Қашан Мен ұяшықты (3, 2) ауыстырып қосамынСодан кейін тор ...................... Х .. тәрізді болуы керек.

Қою басып шығару енгізу құрамына кірмейді; бұл қай тілдің ресми тіл ретінде танылатындығын көрсету үшін енгізілген. JBehave шарттарды таниды Берілген (сценарийдің басталуын анықтайтын алғышарт ретінде), Қашан (оқиғаның триггері ретінде) және Содан кейін (триггерден кейінгі әрекеттің нәтижесі ретінде тексерілуі керек кейінгі шарт ретінде). Осыған сүйене отырып, JBehave сценарийі бар мәтіндік файлды оқи алады талдау оны баптарға бөлу (орнатылған сөйлем, содан кейін тексерілетін шарттармен үш оқиға триггері). Содан кейін Дж.Бивав осы тармақтарды қабылдайды және оларды тест орнатуға, оқиға триггерлеріне жауап беруге және нәтижені тексеруге қабілетті кодқа жібереді. Бұл кодты жоба тобындағы әзірлеушілер жазуы керек (in Java, өйткені бұл JBehave платформасы). Бұл жағдайда код келесідей болуы мүмкін:

жеке Ойын ойын;жеке StringRenderer рендерер;@ Берілген(«a width on $ height» ойыны)қоғамдық жарамсыз theGameIsRunning(int ені, int биіктігі) {    ойын = жаңа Ойын(ені, биіктігі);    рендерер = жаңа StringRenderer();    ойын.setObserver(рендерер);}    @Қашан(«Мен ұяшықты ауыстырамын ($ баған, $ жол)»)қоғамдық жарамсыз iToggleTheCellAt(int баған, int қатар) {    ойын.toggleCellAt(баған, қатар);}@ Содан кейін(«тор $ grid тәрізді болуы керек»)қоғамдық жарамсыз theGridShouldLookLike(Жол тор) {    дәлелде(рендерер.asString(), тең(тор));}

Код сценарийдегі сөйлемнің әр типіне арналған әдіске ие. JBehave қолдану арқылы қай әдіс қай тармақпен жүретінін анықтайды аннотациялар және сценарийді орындау кезінде әр әдісті ретімен шақырады. Сценарийдегі әр тармақтың мәтіні осы тармақтың кодында келтірілген шаблон мәтінімен сәйкес келуі керек (мысалы, Берілген сценарийде «а X by Y ойыны» түріндегі тармақ жалғасады деп күтілуде). JBehave сөйлемдерді шаблондармен сәйкестендіруді қолдайды және шаблоннан терминдерді таңдап, оларды сынақ кодындағы әдістерге параметрлер ретінде беру үшін ішкі қолдауды қолдайды. Сынақ коды сценарийдің әр сөйлем типі үшін орындалуын қамтамасыз етеді, ол тексеріліп жатқан кодпен өзара әрекеттеседі және сценарий негізінде тест жасайды. Бұл жағдайда:

  • The theGameIsRunning әдіс а реакциясына ие Берілген ойынның алғашқы торын орнату арқылы сөйлем.
  • The iToggleTheCellAt әдіс а реакциясына ие Қашан сөйлемде сипатталған ауысу оқиғасын өшіру арқылы сөйлем.
  • The theGridShouldLookLike әдіс а реакциясына ие Содан кейін ойын торының күйін сценарийден күтілетін жағдаймен салыстыру арқылы сөйлем.

Бұл кодтың негізгі функциясы - сюжеті бар мәтіндік файл мен тексерілетін код арасындағы көпір болу. Тест коды тексерілетін кодқа қол жеткізе алатындығын ескеріңіз (бұл жағдайда Ойын) және табиғаты бойынша өте қарапайым. Тест коды қарапайым болуы керек, әйтпесе әзірлеуші ​​өзінің тесттеріне тест жазуы керек.

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

Ерекшелікке қарсы оқиға

Мінез-құлыққа негізделген дамудың жеке ішкі категориясы спецификацияларды емес, енгізу тілі ретінде қолданатын құралдар арқылы қалыптасады пайдаланушы туралы әңгімелер. Бұл стильдің мысалы болып табылады RSpec бастапқыда Дэн Норт жасаған құрал. Техникалық сипаттама құралдары қолданылмайды пайдаланушы туралы әңгімелер үшін енгізу форматы ретінде тест сценарийлері бірақ тексерілетін қондырғылар үшін функционалды сипаттамаларды қолданыңыз. Бұл сипаттамалар көбінесе пайдаланушылар туралы әңгімелерден гөрі техникалық сипатқа ие болады және әдетте пайдаланушылар туралы әңгімелерге қарағанда іскери персоналмен байланысқа онша ыңғайлы емес.[5][31] A сипаттамасының мысалы стек келесідей көрінуі мүмкін:

Ерекшелік: СтекҚашан жаңа стек құрылдыСодан кейін ол босҚашан стекке элемент қосыладыСодан кейін бұл элемент стектің жоғарғы жағында орналасқанҚашан стекте N элемент бар Және элемент Е стектің жоғарғы жағында орналасқанСодан кейін поп операция E қайтарадыЖәне стектің жаңа өлшемі N-1

Мұндай спецификация тексерілетін компоненттің әрекетін дәл көрсете алады, бірақ іскери пайдаланушы үшін онша маңызды емес. Нәтижесінде, спецификацияға негізделген тестілеу BDD тәжірибесінде әңгімеге негізделген тестілеудің толықтырушысы ретінде көрінеді және төменгі деңгейде жұмыс істейді. Ерекшеліктерді тексеру көбінесе еркін форматты ауыстыру ретінде қарастырылады блокты сынау.[31]

RSpec және JDave сияқты техникалық сипаттамаларды тексеру құралдары табиғаты жағынан JBehave сияқты құралдардан біршама ерекшеленеді. Олар негізгі блокты тестілеу құралдарына балама ретінде қарастырылғандықтан JUnit, бұл құралдар әңгіме мен тестілеу кодын бөлуден бас тартуға бейім және оның орнына спецификацияны тікелей тест кодына енгізуді қалайды. Мысалы, a үшін RSpec сынағы хэштеб келесідей көрінуі мүмкін:[32]

сипаттау Хэш істеу  рұқсат етіңіз(: хэш) { Хэш[:Сәлеметсіз бе, 'әлем'] }  бұл { күту(Хэш.жаңа).дейін экв({}) }  бұл «дұрыс ақпаратты кілтке жинайды» істеу    күту(хэш[:Сәлеметсіз бе]).дейін экв('әлем')  Соңы  бұл 'кілтті қамтиды' істеу    хэш.кілттер.қосу?(:Сәлеметсіз бе).керек болуы шын  СоңыСоңы

Бұл мысалда орындалатын кодқа енетін оқылатын тілдегі спецификация көрсетілген. Бұл жағдайда таңдау әдісі аталған әдістерді қосу арқылы спецификация тілін тестілік код тіліне рәсімдеу болып табылады бұл және керек. Сондай-ақ спецификацияның алғышарты деген ұғым бар бұрын бөлім спецификацияға негізделген алғышарттарды белгілейді.

Тест нәтижесі:

 Hash should eq {} кілт кілтінде дұрыс ақпаратты қыстырады

Үш амиго

Үш ерекшеліктер, сондай-ақ «Ерекшеліктер шеберханасы» деп аталады, бұл Өнім иесі СА және даму тобы сияқты әр түрлі мүдделі тараптармен Мысал бойынша сипаттама түріндегі талапты талқылайтын кездесу. Бұл пікірталастың басты мақсаты - сөйлесуді бастау және жетіспейтін ерекшеліктерді анықтау. Талқылау сонымен қатар QA, әзірлеуші ​​топқа және Өнім иесіне талапты байыту үшін бір-бірінің көзқарасын тыңдауға және тыңдауға, сондай-ақ олардың дұрыс өнімді құрып жатқан-жатпағанына көз жеткізуге мүмкіндік береді.[33]

Үш амиго

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

Сондай-ақ қараңыз

Әдебиеттер тізімі

  1. ^ а б в г. e Солтүстік, Дэн (наурыз 2006). «BDD енгізу». Дэн Солтүстік. Алынған 25 сәуір 2019.
  2. ^ а б в «Мінез-құлықты дамыту». Архивтелген түпнұсқа 2015 жылдың 1 қыркүйегінде. Алынған 12 тамыз 2012.
  3. ^ Кеог, Лиз (2009-09-07). «Мінез-құлықты дамытуға кіріспе». SkillsMatter. Алынған 1 мамыр 2019.
  4. ^ Джон Фергюсон Смарт (2014). BDD іс-әрекетте: бүкіл өмірлік цикл үшін мінез-құлыққа негізделген дамыту. Manning басылымдары. ISBN  9781617291654.
  5. ^ а б в г. e f ж сағ мен j к Харинг, Роналд (ақпан 2011). де Рюйтер, Роберт (ред.) «Мінез-құлықты дамыту: Beter dan Test Driven дамыту». Java журналы (голланд тілінде). Veen журналдары (1): 14-17. ISSN  1571-6236.
  6. ^ Солис, Карлос; Ван, Сяофен (2011). «Мінез-құлықты дамыту ерекшеліктерін зерттеу». Бағдарламалық жасақтама жасау және жетілдірілген қосымшалар (SEAA), 2011 ж. 37-ші EUROMICRO конференциясы: 383–387. дои:10.1109 / SEAA.2011.76. hdl:10344/1256. ISBN  978-1-4577-1027-8.
  7. ^ а б в г. Bellware, Scott (маусым 2008). «Мінез-құлықты дамыту». Код журналы. Архивтелген түпнұсқа 2012 жылғы 12 шілдеде. Алынған 1 мамыр 2019.
  8. ^ Тарайл, Ранджит (15 ақпан 2016). «Мінез-құлыққа негізделген даму: күрделі мәселелер кеңістігін жеңілдету». Шешімдер IQ. Алынған 15 ақпан 2018.
  9. ^ Лиз Кеог (27.06.2011). «ATDD қарсы BDD және кейбір байланысты заттардың тарихы». Алынған 6 мамыр 2019.
  10. ^ «RSpec кітабы - 11 тарау туралы сұрақ: маңызды бағдарламалық жасақтама жазу». Архивтелген түпнұсқа 2009-11-07. Алынған 2009-08-09.
  11. ^ Дэн Солтүстік: BDD-ді бизнеске қалай сатуға болады Мұрағатталды 2010-11-25 Wayback Machine
  12. ^ «Лиз Кеог».
  13. ^ GOTO 2013 • Лиз Кеог пен Дэн Нортпен сұхбат https://www.youtube.com/watch?v=g5WpUJk8He4
  14. ^ Д.Норт, RBehave-ті таныстырамын
  15. ^ С.Миллер, InfoQ: RSpec құрамында RBehave бар
  16. ^ а б в г. e Солтүстік, Дэн (11 ақпан 2007). «Әңгімеде не бар?». Дэн Солтүстік. Алынған 12 тамыз 2012.
  17. ^ Мэйби, Бен. «Пайдаланушы тарихындағы императивті және декларативті сценарийлер». Архивтелген түпнұсқа 3 маусымда 2010 ж. Алынған 19 мамыр 2008.
  18. ^ «қысқаша - салат жапырақтары 0.2.23 (криптонит шығарылымы)». салат жапырақтары. Алынған 2020-02-06.
  19. ^ «Геркин». Алынған 7 маусым 2020.
  20. ^ а б «JBehave деген не?». JBehave.org. Алынған 20 қазан 2015.
  21. ^ «өзін ұстау - бұл мінез-құлыққа негізделген даму, Python стилі». Архивтелген түпнұсқа 22 қаңтар 2018 ж. Алынған 30 қаңтар 2018.
  22. ^ «Жазу ерекшеліктері - Behat 3.0.12 құжаттамасы». behat құжаттамасы. Архивтелген түпнұсқа 19 қыркүйек 2015 ж. Алынған 20 қазан 2015.
  23. ^ а б Эванс, Эрик (2003). Доменге негізделген дизайн: бағдарламалық жасақтама күрделілігімен күресу. Аддисон-Уэсли. ISBN  978-0-321-12521-7. Алынған 12 тамыз, 2012.
  24. ^ Солтүстік, Дэн (31 мамыр 2012). «BDD TDD сияқты, егер ...». тезірек ұйымдар, тезірек бағдарламалық жасақтама. Dan North & Associates. Алынған 12 тамыз 2012.
  25. ^ Geneca (16 наурыз 2011). «Бағдарламалық жасақтама неге істен шығады». Алынған 16 наурыз 2011.
  26. ^ Махмудул Хаку Азад (6 ақпан 2011). «Мінез-құлықты дамытуға сәлем». Алынған 12 тамыз 2012.
  27. ^ Любке, Даниэль; ван Лессен, Таммо (2016). «BPMN-де сынақ жағдайларын мінез-құлықты дамыту үшін модельдеу». IEEE бағдарламалық жасақтамасы. 33 (5): 15–21. дои:10.1109 / MS.2016.117.
  28. ^ Адам Крейвен (2015 жылғы 21 қыркүйек). «Кәсіпорын ауқымындағы мінез-құлықты дамыту негіздері (BDD)». Алынған 14 қаңтар 2016.
  29. ^ Кетил Дженсен (13 желтоқсан, 2009). «Fitnesse Slim-тағы сценарий кестелерімен BDD». Жаяу жүріңіз. Wordpress. Алынған 12 тамыз 2012.
  30. ^ «jbehave.org/team-list». Дж. 2017-05-28. Алынған 1 мамыр 2019.
  31. ^ а б Рой Ошеров (2008 ж. 4 қазан). «BDD: мінез-құлық және спецификалық құрылымдар». Алынған 12 тамыз 2012.
  32. ^ Джейсон Сейфер (2011 ж. 7 желтоқсан). «RSpec-ке кіріспе». Алынған 27 қазан 2012.
  33. ^ «Agile-дегі үш амиго қандай?». Agile Alliance. 2016-06-16. Алынған 2019-06-10.