tdd vs bdd analyze differences with examples
Този урок обяснява разликите между TDD срещу BDD с примери:
TDD или Test Driven Development и BDD или Behavior Driven Development са двете техники за разработка на софтуер.
Преди да се потопим по-дълбоко в разликата между тези две, нека първо разберем какво означават те поотделно и как се използват?
Да започваме!!
какво можете да направите с c ++
Какво ще научите:
Какво е TDD?
TDD означава Test Driven Development. В тази техника за разработване на софтуер първо създаваме тестовите случаи и след това записваме кода, който е в основата на тези тестови случаи. Въпреки че TDD е техника за разработка, тя може да се използва и за разработване на тестове за автоматизация.
Екипите, които прилагат TDD, отделят повече време за разработка, но те са склонни да откриват много малко дефекти. TDD води до подобрено качество на кода и кода, който е по-многократен и гъвкав.
TDD също помага за постигане на висок покритие на теста от около 90-100%. Най-голямото предизвикателство за разработчиците след TDD е да напишат своите тестови случаи преди да напишат кода.
Предложено четене => Крайно ръководство за писане на отлични тестови случаи
Процес на TDD
Методологията TDD следва много прост 6-стъпков процес:
1) Напишете тестов случай: Въз основа на изискванията напишете автоматизиран тестов случай.
2) Изпълнете всички тестови случаи: Изпълнете тези автоматизирани тестови случаи на разработения в момента код.
3) Разработете кода за тези тестови случаи: Ако тестът не успее, напишете кода, за да накарате този случай да работи според очакванията.
4) Стартирайте отново тестови случаи: Стартирайте отново тестовите случаи и проверете дали са приложени всички разработени до момента тестови случаи.
5) Рефакторирайте вашия код: Това е незадължителна стъпка. Важно е обаче да рефакторирате кода си, за да го направите по-четлив и повторен.
6) Повторете стъпките 1-5 за нови тестови случаи: Повторете цикъла за останалите тестови случаи, докато всички тестови случаи бъдат приложени.
Пример за внедряване на тестов случай в TDD
Да приемем, че имаме изискване да разработим функционалност за вход за приложение, което има полета за потребителско име и парола и бутон за изпращане.
Етап 1: Създайте тест.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Стъпка 2: Изпълнете този тестов случай и ще получим грешка, в която се казва, че страницата за вход не е дефинирана и няма методи с имена enterUserName, enterPassword и submit.
какво е инструмент за събиране на данни
Стъпка 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: Нека рефакторираме кода, за да даде правилните съобщения за грешка, когато условията if в метода за изпращане не са верни.
//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 за този тестов случай и след това добавете функционалността за обработка на празни низове на потребителско име и парола.
Какво е BDD?
BDD е съкращение от поведенческо развитие. BDD е разширение на TDD, където вместо да пишем тестовите случаи, започваме с писане на поведение. По-късно разработваме кода, който е необходим на нашето приложение за извършване на поведението.
Сценарият, дефиниран в подхода BDD, улеснява сътрудничеството между разработчиците, тестерите и бизнес потребителите.
BDD се счита за най-добрата практика, когато става въпрос за автоматизирано тестване тъй като се фокусира върху поведението на приложението, а не върху мисленето за изпълнението на кода.
Поведението на приложението е в центъра на фокуса в BDD и принуждава разработчиците и тестерите да влязат в обувките на клиента.
Процес на BDD
Процесът, включен в методологията на BDD, също се състои от 6 стъпки и е много подобен на този на TDD.
1) Напишете поведението на приложението: Поведението на приложението е написано на прост английски като език от собственика на продукта или бизнес анализаторите или QA.
2) Напишете автоматизираните скриптове: След това този прост английски език се превръща в тестове за програмиране.
3) Прилагане на функционалния код: След това се изпълнява функционалният код, лежащ в основата на поведението.
4) Проверете дали поведението е успешно: Изпълнете поведението и вижте дали то е успешно. Ако е успешно, преминете към следващото поведение, в противен случай коригирайте грешките във функционалния код, за да постигнете поведението на приложението.
5) Рефакторирайте или организирайте код: Рефакторирайте или организирайте кода си, за да го направите по-четлив и повторно използваем.
6) Повторете стъпките 1-5 за ново поведение: Повторете стъпките, за да внедрите повече поведения във вашето приложение.
Прочетете също => Как тестерите се включват в TDD, BDD и ATDD техники
Пример за прилагане на поведение в BDD
Да приемем, че имаме изискване да разработим функционалност за вход за приложение, което има полета за потребителско име и парола и бутон за изпращане.
Въпроси и отговори за интервю за oracle pl / sql
Етап 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: Внедрете функционалния код (Това е подобно на функционалния код в TDD пример стъпка 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 за примера на TDD.
//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.
TDD срещу BDD - ключови разлики
TDD | BDD |
---|---|
Може да е по-добър подход за проекти, които включват API и инструменти на трети страни. | Може да е по-добър подход за проекти, които се движат от действия на потребителите. Например: уебсайт за електронна търговия, система за кандидатстване и др. |
Стендове за тестово развитие. | Стендове за поведенческо развитие. |
Процесът започва с написване на тестов случай. | Процесът започва с писане на сценарий според очакваното поведение. |
TDD се фокусира върху това как е внедрена функционалността. | BDD се фокусира върху поведението на приложение за крайния потребител. |
Тестовите случаи са написани на език за програмиране. | Сценариите са по-четливи в сравнение с TDD, тъй като са написани в прост английски формат. |
Промени в начина, по който функциите на приложението оказват голямо влияние върху тестовите случаи в TDD. | BDD сценариите не са много засегнати от промените във функционалността. |
Сътрудничество се изисква само между разработчиците. | Необходимо е сътрудничество между всички заинтересовани страни. |
Някои от инструментите, които поддържат TDD, са: JUnit, TestNG, NUnit и др. | Някои от инструментите, които поддържат BDD, са SpecFlow, Cucumber, MSpec и др. |
Тестовете в TDD могат да бъдат разбрани само от хора със знания по програмиране, | Тестовете в BDD могат да бъдат разбрани от всяко лице, включително тези, без никакви познания по програмиране. |
TDD намалява вероятността от грешки в тестовете ви. | Грешките в тестовете са трудни за проследяване в сравнение с TDD. |
Заключение
Изборът между TDD Vs BDD може да бъде много труден. Някои може да твърдят, че BDD е по-добър за намиране на грешки, докато други може просто да кажат, че TDD дава по-голямо покритие на кода.
Нито една от методологиите не е по-добра от другата. Зависи от човека и екипа на проекта да реши коя методология да използва.
Надяваме се, че тази статия е изчистила съмненията ви относно TDD срещу BDD !!
Препоръчително четене
- 180+ Примери за тестване на уеб приложения (примерни контролни списъци)
- Как да преведа ръчни тестови случаи в скриптове за автоматизация? - Ръководство стъпка по стъпка с пример
- Тестови случаи Интервюта: Напишете тестови случаи въз основа на сценарий
- Как тестерите се включват в TDD, BDD и ATDD техники
- Тестово покритие при тестване на софтуер (Съвети за максимално покритие на тестване)
- 8 инструмента за най-добро поведенческо развитие (BDD) и рамки за тестване
- Specflow Tutorial: The Ultimate Guide to BDD Tool
- Как се пишат тестови случаи: Крайното ръководство с примери