Member-only story
Design by Contract vs. Test-Driven Development: A Tale of Two Approaches to Better Code
When it comes to programming, one universal truth reigns supreme: we all want to write reliable, maintainable, and bug-free code. The real question is — how do we get there? Enter Design by Contract (DbC) and Test-Driven Development (TDD), two popular approaches that aim to improve the quality of software but take dramatically different paths to get the job done.
If you’re wondering which approach might work best for you, or whether you can (or should) combine them, let’s dive into the details.
What is Design by Contract (DbC)?
Imagine every part of your codebase entering into a formal agreement — almost like a business contract. That’s the essence of Design by Contract (DbC). This approach, popularized by Bertrand Meyer, emphasizes clear agreements between software components through:
- Preconditions: What must be true before a function runs. Example: A function dividing two numbers might require that the denominator is not zero.
- Postconditions: What will be true after the function has executed successfully. Example: After sorting an array, all elements must be in ascending order.
- Invariants: Rules that must always hold true throughout the program’s execution. Example: A bank account balance should never go negative unless explicitly allowed by an overdraft policy.
