Test Driven Development
What is Test Driven Development?
Why is it important?
Take a moment to answer these.
Did the answers come naturally? Or did you have to think about it? Were you confident in your answer?
I ran a TDD workshop with one of my teams and when I asked this question to a team of developers who talk about TDD, I was surprised to see uncertainty in answering this. I took a different approach to this workshop though…
TDD in a nutshell
- Write a test.
- Watch the test fail.
- Write application logic — as simple as possible
- Pass the test.
- Refactor, removing duplication
- Pass the test again.
Sounds great, doesn’t it?
So how would you apply TDD in legacy code?
I’m not going to tell you what you already know ;-)
A brief history lesson
A developer, Dave Nicolette, who started out in the 70’s said…
“Never touch the keyboard until a rough skeleton idea is on paper”
I’m sure you know this too … right?
But did you know…
TDD…
- originates from Extreme Programming
- is a software design technique
- takes a lot of self-discipline at first
- time-consuming upfront
- speeds up development time and debugging in the long run
- unit tests lets you find bugs earlier
- improve quality
- simplify code
- code documentation
- team members can edit each others code — confidently
- painful at first
- big learning curve at first if not used to working this way
- can make you feel like you going slower
- enables transparency
- is agile
- saves on cost in long run
The twist in my approach to my TDD workshop was asking this question…
Ever heard of The Project Management Trilemma?
Its simple. Choose two.
You can’t have all three.
TDD is great, but it does not work in isolation.
It works in the right environment.
What’s the one thing to remember in your reality?
Theory and understanding of how TDD works are good foundations to start with. It’s also about how we approach our work that‘s important.
If you have an environment that tries to satisfy all three areas GOOD FAST and CHEAP, then you have little time and brain power left to do TDD.
Pick the best practices within your environment, to create the best teams. Don’t try to tick all the ‘check boxes’.
If you can’t do TDD within your environment, then change your environment first. If you can’t change your environment, then don’t do TDD.
A good mindset, focus and time toward TDD plays a substantial role. Its an holistic approach to get the most effective outcomes.
Read. Learn. Teach each other. Find the intersection of the good tech and your reality (environment), and start there.
