Мени

ТДД вс БДД - Анализирајте разлике на примерима

tdd vs bdd analyze differences with examples

Испробајте Наш Инструмент За Елиминисање Проблема

Овај водич објашњава разлике између ТДД и БДД на примерима:

ТДД или Тест Дривен Девелопмент и БДД или Бехавиор Дривен Девелопмент су две технике развоја софтвера.

Пре него што дубље заронимо у разлику између ове две особе, прво схватимо шта они појединачно значе и како се користе?

Почнимо!!

ТДД вс БДД

Шта ћете научити:

Шта је ТДД?

ТДД је скраћеница од Тест Дривен Девелопмент. У овој техници развоја софтвера прво креирамо тест случајеве, а затим напишемо код у основи тих тест случајева. Иако је ТДД техника развоја, може се користити и за развој тестирања аутоматизације.

Тимови који примењују ТДД узимају више времена за развој, међутим, они обично пронађу врло мало недостатака. ТДД резултира побољшаним квалитетом кода и кода који је вишекратно употребљив и флексибилан.

ТДД такође помаже у постизању високог покривеност тестом од око 90-100%. Најизазовније за програмере који прате ТДД је да напишу своје тестове пре писања кода.

Питања и одговори за пословне аналитичаре

Предложено читање => Врхунски водич за писање одличних тест случајева

Процес ТДД-а

ТДД методологија прати врло једноставан процес од 6 корака:

1) Напишите тест случаја: На основу захтева, напишите аутоматски случај.

2) Покрените све тестове: Покрените ове аутоматизоване тест случајеве на тренутно развијеном коду.

3) Развити код за те тест случајеве: Ако тест случај не успе, напишите код да би тест случај радио како се очекивало.

4) Поново покрените тест случајеве: Поново покрените тест случајеве и проверите да ли су примењени сви до сада развијени тест случајеви.

5) Преправите свој код: Ово је опциони корак. Међутим, важно је да преобликујете свој код како бисте га учинили читљивијим и поновнијим.

најбољи начин за преузимање са иоутубе-а у мп3

6) Поновите кораке 1–5 за нове тест случајеве: Понављајте циклус за остале тест случајеве док се сви тест примери не примене.

ТДД дијаграм тока

Пример примене тест случаја у ТДД

Претпоставимо да имамо захтев да развијемо функционалност пријаве за апликацију која има поља за корисничко име и лозинку и дугме за слање.

Корак 1: Направите тест случај.

@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }

ТДД тест случај

Корак 2: Покрените овај тест случај и добићемо грешку која каже да страница за пријављивање није дефинисана и да не постоје методе са именима ентерУсерНаме, ентерПассворд и субмит.

Корак 3: Развијте код за тај тестни случај. Напишимо основни код који ће унети корисничко име и лозинку и добити објект почетне странице када су тачни.

public class LoginPage{ String username; String password; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }

Пример ТДД тест случаја

Корак4: Поново покрените тест случај и добићемо инстанцу почетне странице.

Корак5: Рефакторизирамо код да бисмо дали исправне поруке о грешци када услови иф у методи слања нису тачни.

//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }

Корак 6: Напишимо сада нови тест случај са празним корисничким именом и лозинком.

@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }

Ако покушате да покренете овај тест случај, неће успети. Поновите кораке 1 до 5 за овај тест случај, а затим додајте функционалност за руковање празним низовима корисничког имена и лозинке.

Шта је БДД?

БДД је скраћеница од Бехавиоур Дривен Девелопмент (Развој вођен понашањем). БДД је проширење ТДД-а, где уместо писања тест случајева, започињемо писањем понашања. Касније развијамо код који је потребан нашој апликацији за понашање.

Сценариј дефинисан у БДД приступу олакшава сарадњу програмерима, тестерима и пословним корисницима.

БДД се сматра најбољом праксом када је реч о њему аутоматизовано тестирање јер се фокусира на понашање апликације, а не на размишљање о примени кода.

Понашање апликације је центар фокуса БДД-а и приморава програмере и тестере да уђу у ципеле купца.

Процес БДД-а

Процес укључен у БДД методологију такође се састоји од 6 корака и врло је сличан ономе код ТДД-а.

1) Напишите понашање апликације: Понашање апликације на једноставном енглеском језику, попут језика, написао је власник производа или пословни аналитичари или КА.

2) Напишите аутоматизоване скрипте: Овај једноставан енглески језик налик претвара се у тестове програмирања.

двоструко повезана листа класе ц ++

3) Применити функционални код: Затим се имплементира функционални код у основи понашања.

4) Проверите да ли је понашање успешно: Покрените понашање и погледајте да ли је успешно. Ако успе, пређите на следеће понашање, иначе поправите грешке у функционалном коду да бисте постигли понашање апликације.

5) Рефактор или организовање кода: Рефакторизирајте или организујте свој код како бисте га учинили читљивијим и поновнијим за употребу.

6) Поновите кораке 1-5 за ново понашање: Поновите кораке да бисте применили више понашања у својој апликацији.

Такође прочитајте => Како су тестери укључени у ТДД, БДД и АТДД технике

Пример примене понашања у БДД

Претпоставимо да имамо захтев да развијемо функционалност пријаве за апликацију која има поља за корисничко име и лозинку и дугме за слање.

Корак 1: Напишите понашање апликације за унос корисничког имена и лозинке.

Scenario: Login check Given I am on the login page When I enter 'username' username And I enter 'Password' password And I click on the 'Login' button Then I am able to login successfully.

Корак 2: Напишите скрипту за аутоматизовано тестирање за ово понашање како је приказано доле.

@RunWith(Cucumber.class) public class MyStepDefinitions { @Steps LoginPage loginPage; @Steps HomePage hp; @Given('^I am on the login page $') public void i_am_on_the_login_page(){ loginPage.gotoLoginPage(); } @When('^I enter '((^')*)' username$') public void i_enter_something_username(String username) { loginPage.enterUserName(username); } @When('^I enter '((^')*)' password$') public void i_enter_something_password(String password) { loginPage.enterPassword(password); } @When('^I click on the '((^')*)' button$') public void i_click_on_the_submit_button(String strArg1) { hp = loginPage.submit(); } @Then('^I am able to login successfully.$') public void i_am_able_to_login_successfully() { Assert.assertNotNull(hp); } }

Корак 3: Примените функционални код (Ово је слично функционалном коду у примеру ТДД, корак 3).

public class LoginPage{ String username = ''; String password = ''; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }

Корак4: Покрените ово понашање и погледајте да ли је успешно. Ако је успешна, идите на корак 5, у супротном исправите грешку у функционалној имплементацији, а затим је поново покрените.

Корак5: Рефакторирање имплементације је необавезни корак и у овом случају можемо да преправимо код у методи за слање како бисмо исписали поруке о грешкама као што је приказано у кораку 5 за пример ТДД.

//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }

Корак 6: Напишите ново понашање и следите кораке 1 до 5 за ово ново понашање.

Можемо да напишемо ново понашање како бисмо проверили да ли имамо грешку јер нисмо унели корисничко име као што је приказано доле:

Scenario: Login check Given I am on the login page And I click on the 'Login' button Then I get an error to enter username.

ТДД против БДД - кључне разлике

ТДДБДД
Можда је бољи приступ за пројекте који укључују АПИ и независне алате.Могао би бити бољи приступ за пројекте који се покрећу корисничким деловањем. На пример: веб локација за е-трговину, систем апликација итд.
Штандови за развој вођен тестом.Значи за развој вођен понашањем.
Процес започиње писањем тест случаја.Процес започиње писањем сценарија према очекиваном понашању.
ТДД се фокусира на то како је функционалност имплементирана.БДД се фокусира на понашање апликације за крајњег корисника.
Тест примери су написани на програмском језику.Сценарији су читљивији у поређењу са ТДД-ом јер су написани у једноставном енглеском формату.
Промене у начину функционисања апликације много утичу на тест случајеве у ТДД-у.Промене функционалности не утичу много на БДД сценарије.
Сарадња је потребна само између програмера.Потребна је сарадња између свих заинтересованих страна.
Неки од алата који подржавају ТДД су: ЈУнит, ТестНГ, НУнит итд.Неки од алата који подржавају БДД су СпецФлов, Цуцумбер, МСпец итд.
Тестове у ТДД могу да разумеју само људи са програмским знањем,Тестове у БДД-у може да разуме било која особа, укључујући оне без знања програмирања.
ТДД смањује вероватноћу постојања грешака у тестовима.Грешке у тестовима је тешко пратити у поређењу са ТДД-ом.

Закључак

Избор између ТДД-а и БДД-а може бити врло лукав. Неки би могли тврдити да је БДД бољи за проналажење грешака, док би други могли рећи да ТДД пружа већу покривеност кодом.

Ниједна методологија није боља од друге. О томе ко ће користити методологију зависи од особе и пројектног тима.

Надамо се да је овај чланак разјаснио ваше сумње у вези са ТДД и БДД !!

Препоручено читање

^