How Test‑Driven Development Transforms Code Quality and Design

Concept

Test‑Driven Development (TDD) means “write code only to fix failing tests.” First a test is written, then code is added to make the test pass. With sufficient tests, developers can refactor confidently, improving design, producing testable code, and avoiding over‑design based on unrealistic assumptions.

Goal

Improve internal application quality with TDD and ensure delivered software meets user needs using ATDD/BDD.

At the coding level, TDD drives code writing; at the requirements level, BDD drives system construction.

Principles

Write test code first, then the code that satisfies the test; aim to have test code for each code segment.

Tests need not cover every detail but must address major functionality and potential error points.

When a bug is found, write a corresponding test case before debugging.

Continuously analyze bug causes and add related tests.

Maintain test code so all tests pass after any code change.

Keep test code readable and maintainable.

Follow the testing pyramid: unit tests > BDD > manual tests.

Standards

General

Test code is code and must be under source control.

Test code does not need its own tests but requires code review.

Unit and BDD test code should reside in the same project as production code, separated by directories.

E2E regression test code can be in a separate project.

Unit, acceptance, and BDD tests must be automatable.

Different tech stacks may use different automation frameworks, but all must integrate with the DevOps platform to trigger tests and report results.

Each push should trigger unit tests and report outcomes.

It is recommended that each push also trigger BDD tests.

Daily full‑regression E2E tests are recommended.

Unit Testing

Project naming convention: [ProjectName].Unit.Tests (e.g., abc.service.unit.tests).

Test file naming: [ClassName]Tests (e.g., bookServiceTests.java).

Method naming pattern: [method]_[scenario]_[expectedResult] (e.g., Add_SingleNumber_ReturnsSameNumber).

Test methods must follow the Arrange‑Act‑Assert structure.

BDD

Do not replace unit tests with BDD; developers should first have solid unit tests.

If BDD execution exceeds 15 minutes, improve test code.

BDD tests use Gherkin syntax (Given‑When‑Then).

Place feature files in src/tests/features/, organized by functional sub‑directories.

Step definitions go in src/tests/features/steps/, mirroring the feature folder structure.

Group related tests in a single .feature file.

Each feature must be runnable independently without affecting others.

Avoid encoding story IDs in feature file names.

Recommended Practices

Development Phase

QA writes BDD scenarios for user stories and gets SDE/TPM confirmation.

SDE writes unit tests and business code, assisting QA with BDD code.

Test!

Each code commit triggers DevOps to produce two results: unit‑test outcome and impact on test coverage.

After a merge request, each commit also produces a BDD test result.

Run nightly regression tests and push reports to the whole team.

QA helps TPM write acceptance criteria for the next sprint; only when BDD‑written criteria pass and are BPM‑approved does the story become Ready.

Metrics

Coverage metrics: method, branch, and line coverage.

Code deployed to production must achieve 100% test pass rate.

Track daily BDD test pass‑rate trends within a sprint.