Test Driven Development (TDD) :

TDD (Test-Driven Development) and BDD (Behavior-Driven Development) are two

software development methodologies that emphasize testing and specifying the
expected behavior of software systems. While they share some similarities, they
also have distinct approaches and purposes.

1. Test-Driven Development (TDD):

1.Add test case
TDD is a development methodology that focuses on writing tests before writing 2.Run the test cases and watch test fails
the actual code. The process typically follows these steps:
3.Update the code
a. Write a failing test: Start by defining a test case that describes the desired 4.Run the test cases again
behavior of a small piece of functionality. This test will initially fail since the code 5.Refactor the code (Optional)
to implement that functionality doesn't exist yet. 6.Repeat the steps for another test case
b. Write the minimum code: Write the minimum amount of code necessary to
make the test pass. This often means creating a function or method that fulfills
the test's requirements.

c. Refactor and optimize: Once the test passes, you can refactor and optimize
the code while ensuring that the test continues to pass. This helps maintain and
improve code quality.

d. Repeat: Continue this cycle, adding more tests and code in small increments,
ensuring that all tests pass at each step. This iterative process leads to a
comprehensive suite of tests and well-structured code.
Behavior Driven Development (BDD) :

2. Behavior-Driven Development (BDD):

BDD is an extension of TDD that shifts the focus from testing to describing the
behavior of the system from a user's perspective. It emphasizes collaboration
between developers, testers, and domain experts (often referred to as
"stakeholders"). BDD typically involves the following components:

a. Specifications/Scenarios: Instead of writing traditional unit tests, BDD

starts with writing scenarios that describe the expected behavior of a system 1.Write the behavior of the application
or a specific feature. These scenarios are often written in plain language and 2.Write the automated scripts
follow the "Given-When-Then" format to describe the context, action, and 3.Then Implement the functional code
expected outcomes.
4.Check if the behavior is successful and if
b. Automation: These scenarios are then automated using BDD frameworks not success then fix it
like Cucumber, SpecFlow, or Behave, which can execute the specifications as 5.Organize the code (Optional)
tests. This automation ensures that the software behaves as specified in the 6.Repeat the steps for another behavior
scenarios.

c. Collaboration: BDD encourages collaboration between technical and non-

technical team members to define and refine specifications. It helps ensure
that the software aligns with business goals and requirements.

BDD helps bridge the communication gap between technical and non-technical
team members by providing a shared language for discussing system behavior.
It promotes a more holistic view of the software and its interactions with users.
Summary, TDD focuses on
writing tests to verify the correctness
of individual code components, while
BDD focuses on specifying the
expected behavior of the entire
system from a user's perspective.
Both methodologies promote testing
and can lead to more robust and
maintainable software when
implemented effectively. The choice
between TDD and BDD often
depends on the project's specific
requirements and the team's
preferred approach to development
and collaboration.
Example: TDD Scenario: Adding Two Numbers

1. **Write a Failing Test:**

- In TDD, you start by writing a test case that defines the behavior
you want to implement. For our example, you might write a test in a
testing framework like JUnit for Java.

```java
public void testAddition() {
Calculator calculator = new Calculator();
int result = calculator.add(2, 3);
assertEquals(5, result);
}
```
2. **Write the Minimum Code:**
- Now, you implement the `Calculator` class with the `add` method
to make the test pass.

```java
public class Calculator {
public int add(int a, int b) {
return a + b;
}
}
Example: BDD Scenario: Adding Two Numbers - This scenario describes the behavior of adding two numbers using the calculator.

2. **Automation:**
- You then automate the scenario using a BDD framework, linking it to code that implements
the behavior.
**Refactor and Optimize:** ```java
- Once the test passes, you can refactor and optimize the code @Given("I have a calculator")
if needed. public void i_have_a_calculator() {
// Initialization code for the calculator
}
**BDD Approach:**
@When("I add {int} and {int}")
1. **Write a Scenario:** public void i_add(int a, int b) {
// Code to perform addition
- In BDD, you start by writing a scenario using a BDD framework int result = calculator.add(a, b);
like Cucumber in plain language. // Store the result for later verification
context.setResult(result);
```gherkin }
Scenario: Adding two numbers @Then("the result should be {int}")
Given I have a calculator public void the_result_should_be(int expected) {
When I add 2 and 3 int actual = context.getResult();
assertEquals(expected, actual);
Then the result should be 5 }
```

**Collaboration:**
- Throughout the process, team members, including non-technical stakeholders, can collaborate to define and refine the
scenario, ensuring it aligns with the desired behavior.
Why BDD Framework?

Let's assume there is a requirement from a client for an

E-Commerce website to increase the sales of the product
with implementing some new features on the website.
The only challenge of the development team is to
convert the client idea into something that actually
delivers the benefits to client.

The original idea is awesome. But the only challenge

here is that the person who is developing the idea is not
the same person who has this idea. If the person who
has the idea happens to be a talented software
developer, then we might be in luck: the idea could be
turned into working software without ever needing to be
explained to anyone else. Now the idea needs to be
communicated and has to travel from Business
Owners(Client) to the development teams or many other
people.

Most software projects involve teams of several people

working collaboratively together, so high-quality
communication is critical to their success. As you
probably know, good communication isn’t just about
eloquently describing your ideas to others; you also need
to solicit feedback to ensure you’ve been understood
correctly. This is why agile software teams have learned
to work in small increments, using the software that’s
built incrementally as the feedback that says to the
stakeholders “Is this what you mean?”
Below image is the example of what clients have in their
mind and communicated to the team of developers and
how developers understands it and work on it.
Features of BDD:

1.Shifting from thinking in "tests" to thinking in "behavior"

2.Collaboration between Business stakeholders, Business Analysts, QA Team and developers
3.Ubiquitous language, it is easy to describe
4.Driven by Business Value
5.Extends Test-Driven Development (TDD) by utilizing natural language that non-technical stakeholders
can understand
6.BDD frameworks such as Cucumber or JBehave are an enabler, acting a "bridge" between Business &
Technical Language

What is Cucumber?
Cucumber is a testing framework which
supports Behavior Driven Development (BDD). It lets us
define application behavior in plain meaningful English
text using a simple grammar defined by a language
called Gherkin. Cucumber itself is written in Ruby, but it
can be used to “test” code written in Ruby or other
languages including but not limited
to Java, C# and Python.