I have a passion for software development and cooking is one of my favorite hobby. At first, they seem different. One is digital, the other is delicious! But they actually follow the same philosophy.
What is TDD/BDD anyway?
Some people think Test/Behavior-Driven Development (TDD/BDD) means writing every test case before you write any code. That’s not true.
It’s actually about a cycle:
- Red: Write a small test that fails.
- Green: Write just enough code to make it pass.
- Refactor: Clean up the code.
- Repeat: Start over from Step 1.
Here is how that looks in my kitchen:
1. The "Taste Profile" (BDD)
Before I start, I decide what the dish should be.
- The Goal: "A spicy tomato soup with a hint of garlic."
- The Initial State: Right now, I just have a pot of plain water.
- The Result: If I taste it now, it fails. It’s not spicy, garlicky or even soup yet! This is my "failing case" that guides me.
2. Add and Test (TDD)
I don’t throw all the spices or salt in at once. I go step-by-step:
- Step 1: I add chili. I taste it. Still not spicy enough? (Test Fails).
- Step 2: I add more chili. I taste it again. Now it's spicy! (Test Passes).
- Step 3: Now I add the garlic. I repeat the process.
3. Cleaning the Kitchen (Refactoring)
In code, we refactor to make it clean. In cooking, I might strain the soup to make it smooth or adjust the heat. I am not changing the flavor (the behavior); I am just making the quality better.
Why does this work?
- No Surprises: I know exactly when the "flavor" is right.
- Safety Net: If I add too much salt, I know immediately because I am testing (tasting) as I go.
- Evolution: The recipe evolves with the dish, just like code evolves with the project.
My Advice
Don't just build it and hope for the best at the end. Taste your code as you go!
Top comments (0)