{"id":12,"date":"2019-06-17T09:53:39","date_gmt":"2019-06-17T09:53:39","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=12"},"modified":"2019-06-17T10:18:00","modified_gmt":"2019-06-17T10:18:00","slug":"bdd-vs-tdd-testing","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/bdd-vs-tdd-testing\/","title":{"rendered":"BDD vs TDD testing"},"content":{"rendered":"\n
When you look at any reference on Behavior Driven Development, you will find the usage of phrases such as \u201cBDD is derived from TDD\u201d, \u201cBDD and TDD\u201d. To know how BDD came into existence, why it is said to be derived from TDD and what is BDD and TDD, you have to have an understanding of TDD.<\/p>\n\n\n\n
To start, let us get into the fundamentals of testing. The purpose of testing is to ensure that the system that is built is working as expected. Consider the following example.<\/p>\n\n\n\n Hence, by experience we have learnt that uncovering a defect as and when it is introduced and fixing it immediately would be cost effective. Therefore, there is a necessity of writing test cases at every stage of development and testing. This is what our traditional testing practices have taught us, which is often termed as Test-early.<\/p>\n\n\n\n This testing approach is termed as the Test-Last approach as testing is done after the completion of a stage.<\/p>\n\n\n\n The Test-Last approach was followed for quite some time in the software development projects. However, in reality, with this approach, as testing has to wait till the particular stage is completed, often it is overlooked because of \u2212<\/p>\n\n\n\n Further, in the Test-Last approach, Unit testing, that is supposed to be done by the developers is often skipped. The various reasons found are based on the mind-set of the developers \u2212<\/p>\n\n\n\n This results in \u2212<\/p>\n\n\n\n These factors called for a shift in paradigm, to focus on testing. The result was the Test-First approach.<\/p>\n\n\n\n The Test-First approach replaces the inside-out (write code and then test) to outside-in (write test and then code) way of development.<\/p>\n\n\n\n This approach is incorporated into the following software development methodologies (that are Agile also) \u2212<\/p>\n\n\n\n In these methodologies, the developer designs and writes the Unit tests for a code module before writing a single line of the code module. The developer then creates the code module with the goal of passing the Unit test. Thus, these methodologies use Unit testing to drive the development.<\/p>\n\n\n\n The fundamental point to note that the goal is development based on testing.<\/p>\n\n\n\n Test Driven Development is used to develop the code guided by Unit tests.<\/p>\n\n\n\n Step 1<\/strong> \u2212 Consider a code module that is to be written.<\/p>\n\n\n\n Step 2<\/strong> \u2212 Write a test<\/p>\n\n\n\n Step 3<\/strong> \u2212 Run the test.<\/p>\n\n\n\n The test fails, as the code is still not written. Hence, Step 2 is usually referred to as write a test to fail.<\/p>\n\n\n\n Step 4<\/strong> \u2212 Write minimum code possible to pass the test.<\/p>\n\n\n\n Step 5<\/strong> \u2212 Run all the tests to ensure that they all still pass. Unit tests are automated to facilitate this step.<\/p>\n\n\n\n Step 6<\/strong> \u2212 Refactor.<\/p>\n\n\n\n Step 7<\/strong> \u2212 Repeat Step 1 to Step 6 for the next code module.<\/p>\n\n\n\n Each cycle should be very short, and a typical hour should contain many cycles.<\/p>\n\n\n\n This is also popularly known as the Red-Green-Refactor<\/strong> cycle, where \u2212<\/p>\n\n\n\n The steps of a TDD process are illustrated below.<\/p>\n\n\n\n The benefits or advantages of Test Driven Development are \u2212<\/p>\n\n\n\n The starting point is User Stories, describing the behavior of the system. Hence, the developers often face the following questions \u2212<\/p>\n\n\n\n The following misconceptions exist in the industry and need clarifications.<\/p>\n\n\n\n Acceptance Test Driven Development (ATDD) defines Acceptance Criteria and Acceptance Tests during the creation of User Stories, early in development. ATDD focuses on the communication and common understanding among the customers, developers and the testers.<\/p>\n\n\n\n The Key practices in ATDD are as follows \u2212<\/p>\n\n\n\n The benefits of using ATDD are as follows \u2212<\/p>\n\n\n\nChallenges with Test-Last Approach<\/h2>\n\n\n\n
Test-First Approach<\/h2>\n\n\n\n
Red-Green-Refactor Cycle<\/h2>\n\n\n\n
TDD Process Steps<\/h2>\n\n\n\n
Advantages of TDD<\/h2>\n\n\n\n
Disadvantages of TDD<\/h2>\n\n\n\n
Misconceptions about TDD<\/h2>\n\n\n\n
Misconception<\/th> Clarification<\/th><\/tr> TDD is all about testing and test automation.<\/td> TDD is a development methodology using Test-First approach.<\/td><\/tr> TDD does not involve any design.<\/td> TDD includes critical analysis and design based on the requirements. The design emerges during development.<\/td><\/tr> TDD is only at Unit level.<\/td> TDD can be used at the integration and system levels.<\/td><\/tr> TDD cannot be used by traditional testing projects.<\/td> TDD became popular with Extreme Programming and is being used in other Agile methodologies. However, it can be used in traditional testing projects as well.<\/td><\/tr> TDD is a tool.<\/td> TDD is a development methodology, and after every new Unit Test passes, it is added to the Automation Test Suite as all the tests need to be run whenever a new code is added or existing code is modified and also after every refactoring.Thus, Test Automation Tools supporting TDD facilitate this process.<\/td><\/tr> TDD means handing Acceptance tests to the developers.<\/td> TDD does not mean handing Acceptance Tests to the developers.<\/td><\/tr><\/tbody><\/table>\n\n\n\n Acceptance TDD<\/h2>\n\n\n\n