ATDD, BDD, FDD ,TDD:

TDD- Test Driven Development, Behavior Driven Development & Acceptance Test-Driven Development

First lets list out what exactly each methodology does mean

Test Driven Development (TDD) which is a process of writing tests before writing code and make the test fail. Now write enough code so that the test can pass and then at last refactor the code as per your requirement and make sure the test is passing again after the change. This is it. This is the simplest way of explaining TDD in my opinion. Now, the main focus of TDD will be on testing the low-level functionality and units (for single classes and methods) that can lead to more flexible code and easier refactoring. In a simple language we can say, we write these tests to check if the code we wrote works fine

It’s also called test-driven design, is a method of software development in which unit testing is repeatedly done in the source code. Write your tests watch it fails and then refactor it. After each test, refactoring is done and then the same or a similar test is performed again. The process is iterated as many times as necessary until each unit is functionally working as expected. TDD was introduced first by XP. I believe I have explained enough in simple terms.

BDD – Behavior Driven Development
Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design

Behavior-Driven Development (BDD) and why was that needed? Well, BDD is similar in many ways to TDD except that the word “test” is replaced with the word “spec”. Basically, BDD focuses on the behaviors of your system exhibits than the implementation details of it.

The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the language of Domain Driven Design to describe the purpose and benefit of their code. This allows the developers to focus on “Does my code do what it’s supposed to do?” in addition to “Does my code work?”

DDD-Domain Driven Testing
BDD is similar in many ways to TDD except that the word “test” is replaced with the word “Behavior”. Its purpose is to help the folks devising the system (i.e., the developer) identifies appropriate tests to write–that is, tests that reflect the behavior desired by the stakeholders. BDD is usually done in a very English-like language helps the Domain experts to understand the implementation rather than exposing the code level tests. It’s defined in a GWT format, GIVEN WHEN & THEN.

Dan North first introduced the BDD Style of methodology

ATDD – Acceptance Test Driven Development.

Acceptance Test Driven Development (ATDD) that adds ‘A’ before TDD which stands for Acceptance. Now, why was this even needed? Wasn’t the TDD good enough and better? I would say no and the reason was that TDD was more telling to make sure the code works fine, but it did not say that if the code that is written was even required at first place. In ATDD the acceptance criteria are defined early in the application development process and then those criteria can be used to guide the subsequent development work.

ATDD is a collaborative exercise that involves product owners, business analysts, testers, and developers. ATDD helps to ensure that all project members understand precisely what needs to be done and implemented.
ATDD is a collaborative practice where users, testers, and developers define automated acceptance criteria early in the development process. ATDD helps to ensure that all project members understand precisely what needs to be done and implemented. This workflow usually involves establishing the criteria first, most often from a user perspective, and creating concrete examples. Thereafter, acceptance tests are developed and run to see the results of failure with the right code based on these examples. Minimal code is then developed to run the program, more acceptance tests are run again, and the results are validated. Refactoring is then carried out based on the results of the acceptance tests before the final program is developed for use.

With that, the basic definition of the terms explained above, we will see the differences

Few, Differences between TDD, BDD, FDD and ATDD

• BDD focuses on the behavioral aspect of the system rather unlike the TDD focuses on the implementation aspect of the system.
• ATDD focuses on capturing requirements in acceptance tests and uses them to drive the development. It seems like ATDD focuses on external quality of the software (does the system do what it is required to do?).
• ATDD leans towards the developer-focused side of things like [Unit] TDD does, the BDD is where the step of making it more customer-focused comes in.
• As discussed earlier, the immediate, obvious difference between TDD and ATDD is the ‘A’. While that may sound sarcastic, the point is that TDD (as usually practiced) has an implied U on the front, standing for Unit, while the A stands for Acceptance. TDD focuses on the low level, ATDD on high level.
• BDD is usually done in a very English-like language, and often with further tools to make it easy for non-techies to understand, like Fitness for example. This allows much easier collaboration with non-techie stakeholders, than TDD.
• By contrast, TDD tools and techniques are usually much more techie in nature, requiring that you become familiar with the detailed object model (or in fact create the object model in the process, if doing true test-first canonical TDD). The typical non-programming executive stakeholder would be utterly lost trying to follow along with TDD, let alone participate, and frankly shouldn’t be involved with that level of detail.
• BDD focuses on the behavioral aspect of the system rather than the implementation aspect of the system that TDD focuses on. BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer. TDD only gives the developer an understanding of what the system should do
• FDD (Feature Driven Development) is a method to develop softwares. FDD recommends feature based development. The sprints, team and deliver is based on features