TDD Benefits

Good

TDD cycle defines

Write a failing test for one requirement.

Implement just enough code to make the test pass.

Refactor with confidence (if it’s needed).

Repeat process.

Some clarifications about TDD

TDD is neither about "Testing" nor about "Design".

TDD does not mean "write some of the tests, then build a system that passes the tests.

TDD does not mean "do lots of Testing."

does not replace traditional testing, instead it defines a proven way to ensure effective unit testing

is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code

TDD

is to write and correct the failed tests before writing new code (before development)

Eliminates fear of change. If a code change introduces a bug, developers are alerted to it quickly, and TDD’s tight feedback loop will quickly notify them when it’s fixed.

A safety net which makes continuous deployment safer. Test failures halt the deployment process, allowing you to fix bugs before customers ever have the chance to see them.

40% — 80% fewer bugs.

Better code coverage than writing tests after the fact. Because we create code to make a specific test pass, code coverage will be close to 100%.

Faster developer feedback loop. Without TDD, developers must manually test each change to ensure that it works. With TDD, unit tests can run on-change automatically, providing faster feedback during development and debugging sessions.

Interface design aid: Developers often think about the software implementation before thinking about the developer experience of using the software component. TDD flips this around, forcing developers to design the API before working on the implementation.

KISS and YAGNI — “Keep it Simple, Stupid”, and “You Ain’t Gonna Need It” are two overlapping software design principles. KISS means just like what it sounds like it means. Keep things simple. YAGNI means don’t build features and abstractions unless those features serve a specific existing requirement (not a future requirement). TDD helps with that process by forcing you to work in small iterations, tackling one requirement at a time on an as-needed basis.

TDD Costs
Users without TDD experience may find they move 15% — 30% slower, but with 1–2 year’s practice, TDD’s realtime feedback process can enhance productivity.

TDD & Scientific Method

Scientific Method

Question

Prediction

Experiment

TDD

Requirement

Expected Output

Test Assertion

Subject

Implementation Code

Better organized (plan before code)

More testable (no rewriting code for tests)

Behavioral Driven Development(BDD)

image

benefits

Helps reach a wider audience by the usage of non-technical language

Focuses on how the system should behave from the customer’s and the developer’s perspective

BDD is a cost-effective technique

Reduces efforts needed to verify any post-deployment defects

How does BDD help in SDLC

Allowing the requirements to be defined in a standard approach using simple English

Providing several ways to illustrate real-world scenarios for understanding requirements

Providing a platform that enables the tech and non-tech teams to collaborate and understand the requirements

tests are mainly based on systems behavior. This approach defines various ways to develop a feature based on its behavior

the Given-When-Then approach is used for writing test cases

Given the user has entered valid login credentials

When a user clicks on the login button

Then display the successful validation message

Benefits

Helps reduce the amount of time required for rework

Helps explore bugs or errors very quickly

Help get faster feedback

Encourages the development of cleaner and better designs

Enhances the productivity of the programmer

Allows any team member to start working on the code in the absence of a specific team member. This encourages knowledge sharing and collaboration

Gives the programmer confidence to change the large architecture of an application easily

Results in the creation of extensive code that is flexible and easy to maintain

automated test scripts are written before functional pieces of code

In this technique, a QA engineer starts designing and writing test cases for every small functionality of an application. This technique attempts to answer a simple question – Is the code valid? The main intention of this technique is to modify or write a fresh code only when the test fails. Hence it results in lesser duplication of test scripts. This technique is largely popular in agile development ecosystems.

to avoid duplication of code as we write a small amount of code at a time in order to pass tests.

Acceptance Test-Driven Development(ATDD)

Benefits

The acceptance test serves as a guide for the entire development process

Encourages collaboration among cross-team members

Requirements are very clearly analyzed without any ambiguity

defining the acceptance criteria

Focusing on the development of those requirement cases

Automating the acceptance test cases

Deciding the acceptance criteria for those test scenarios

Analyzing and discussing the real-world scenarios

a single acceptance test is written from the user’s perspective. It mainly focuses on satisfying the functional behavior of the system. This technique attempts to answer the question – Is the code working as expected?

Note: Acceptance Test-Driven Development is very similar to Behavioral-Driven Development. However, a key difference between them is: BDD focuses more on the behavior of the feature, whereas ATDD focuses on capturing the accurate requirements.

image

More on User test not unit test

image

Advantages

Disadvantage

BDD ensures that business gets what expected

Improves communication inside a team

Easy to start with

Software design follows business value

Lower costs of development

Can't cover non-functional requirements

Communication with stakeholders(not true disadvantage)

is not specification for developer

Documentation maintenence

Hard to implement on already existing project

Process

Select user story

Write acceptance test

Implement user story

Run acceptance test

(Refactor)

Get sign off

image

TDD+BDD=ATTD