TDD, FDD & BDD.
3 development practices I couldn’t live without…
Test, Feature and Behaviour driven development are 3 development practices that are great to make part of your daily process. I’m at a stage now where I use all 3 together on both personal and work projects.
I’ve been practicing TDD now for well over 5 years and it’s a process I really couldn’t see myself moving away from. Writing a test first, watching it fail then writing enough of the implementation to make it pass then re-factor originally seemed like an alien concept that was going to make the development process longer.
Tools such as guard for Ruby and grunt for Node.js have helped no end allowing tests to be run immediately on the save of a file and having a growl notification means I no longer need to switch from my editor to a terminal window.
Get David White’s stories in your inbox
Join Medium for free to get updates from this writer.
FDD is a process I kind of fell into from having an interest in Agile / XP development methodologies. It’s more than just splitting up a project into features but involves prioritisation and planning. I’ve been doing FDD now for about as long as if not longer than TDD, though I may not have known the exact name for this type of development.
FDD has really helped me think about and begin modelling a system before any development begins. When used with teams of people it helps to break large features down into smaller more manageable pieces of work.
When I first came across BDD or more specifically cucumber, I had a similar kind of skepticism to when I came across TDD. The idea that we would be running tests based off plain english language user stories that needed to be written up front with stake-holders seemed like an impossible task.
While getting into the habit of writing features / scenarios was not a smooth a transition as getting into the TDD process, it really takes time and considerable effort to get a nice language and style to your feature files. The outside in approach of BDD is a great way of putting any implementation details aside and focusing on the functionality and the user journey.
BDD takes a lot of the good ideas from FDD, allowing you to break a set of features down into smaller features or a series of scenarios that are able to be developed independent of each other.
In my own experience these 3 processes have really helped me write code that I feel is both adding value to a project and have enough confidence in shipping to a live environment. It’s taken a while for the BDD process to feel like it fits into my daily programming routine, especially on personal projects and was only when I started removing the unnecessary details from scenarios that it really clicked.
