TDD — Test-Driven Development

Test-Driven Development is a software development discipline where tests are written before the production code. The cycle is Red (write a failing test), Green (write the minimum code to pass the test), Refactor (improve the code while keeping tests green). TDD results in higher test coverage, simpler code, and better-understood requirements.

Why companies use it

·Produces a comprehensive test suite as a natural by-product of development, not as a separate activity
·Forces engineers to understand requirements precisely before writing code — a failing test cannot be written for an unclear requirement
·Results in more modular, loosely coupled code because tightly coupled code is difficult to test
·In regulated software (IEC 62304 Class C, DO-178C Level A), high unit test coverage is required — TDD is the most reliable way to achieve it

What hiring managers look for

·TDD discipline signals a candidate who prioritises code quality and long-term maintainability over short-term speed
·Unit testing experience (pytest, Google Test, JUnit, Catch2) is expected for most software engineering roles
·The ability to write testable code (dependency injection, interface segregation) is a design skill closely linked to TDD
·In safety-critical embedded software, 100% MC/DC coverage is required — TDD practitioners achieve this more reliably than retrofit testers

Typical interview questions

Describe the Red-Green-Refactor cycle of TDD. Why do you write the test first?

How do you test a function that depends on hardware I/O or an external service?

What is the difference between a unit test, an integration test, and a system test?

When is TDD not appropriate?

Describe a piece of code you have written using TDD. What was the function and what tests did you write?

Common mistakes

·Writing tests after the code is complete and calling it TDD — retrofit tests are useful, but miss the design benefits of test-first development
·Writing tests that test implementation details rather than behaviour — brittle tests that break on every refactor reduce developer confidence in the test suite
·Not mocking external dependencies in unit tests — unit tests must run in isolation; tests that depend on databases or hardware are integration tests
·Writing only happy-path tests — edge cases and error paths are where bugs live
·Using TDD for exploratory or research code where the requirements are genuinely unknown — TDD suits well-understood requirements

Real engineering example

A firmware engineer developing a CAN bus message parser used TDD to develop a safety-critical state machine in an automotive ECU. Writing tests first forced explicit specification of all expected state transitions, including edge cases: partial messages, CRC errors, and timeout conditions. When the code was integrated with the actual CAN hardware, all specified edge cases were already handled correctly. Code review found the implementation to be unusually clear and well-structured because the TDD cycle had naturally enforced single-responsibility functions.

Topics covered

TDDtest-driven developmentunit testingRed-Green-Refactorsoftware quality

Related interview guides

Software Engineer →Embedded Software Engineer →Firmware Engineer →

More in Software Engineering

Git — Version Control for Engineers4 min CI/CD — Continuous Integration and Delivery5 min Code Review — Engineering Quality Gate4 min Software Architecture — Design for Scale6 min DevOps — Development and Operations Integration5 min

Preparing for an interview?

Browse our role-specific interview guides written by engineers who know what hiring managers at ASML, NXP, and Philips look for.

Browse Interview Guides →