Finally unlocking the secrets of Test-Driven Development (TDD)!
Here’s what I’ve been getting wrong all these years…
I never understood TDD. In some cases you know the requirements to create tests, but often I don’t.
Coding is for me research, designing, and trying out multiple things. How can I write tests for something I’m still crafting?
But in the last year, I’m starting to get some new insights about TDD and how to use it when crafting my code.
1) The right level of your tests
More and more I code my logic into message handlers. These handlers are the sweet spot for testing. Not too low level, too detailed, but also not too high level that it gets to abstracted.
Why is this important for TDD?
Because the flow for TDD is: Test -> Implementation -> (Optional) Refactor.
The refactoring should not force you to change the test. This will happen if the test is too low level.
If it is too high level, it isn’t driving the design of your implementation.
2) KISS (Write stupid simple code)
You know those junior programmers that always deliver fast (and get praise for it π€¨). It works for the happy path but fails for anything else.
Be like them when you’re writing the implementation. Write your code as stupidly simple as possible. Just get it to work as fast as possible!
Only when it works do you start adding more test and/or refactor.
3) Write one test, then implement
TDD is all about being agile. I didn’t get this for a long time until I see this video: https://www.youtube.com/watch?v=rdLO7pSVrMY
You don’t write all your test at once. This is what a lot of people get wrong about TDD, me included.
You start with one test and implement that. Then you write your second test.
πWhat are your takeaways from my insights about TDD? Disagree? Completely agree? Something in between? Let me know!
