Let`s discuss the importance of test-driven development. First and foremost, if the terms TDD or BDD, which are short for test- and behavior-driven development, are foreign to you, they are the practice of building code tests for applications.
And even more specifically, TDD and BDD are software development processes in which you create a test that sets an expectation before implementing any code.
An example of using TDD to create a feature for returning a full name from a user class would be to:
- Create a test that calls a new method, such as
full_name, that combines the first and last name of a user and returns a string combining the names into a single value:
- Then we'd run the test, knowing that it will fail:
- Then we would go and add a barebones implementation of the code:
This will get the test passing:
- Then we'd go back and refactor the implementation to ensure it conforms to best practices and that the refactor doesn't break anything:
This process is known as the Red, Green, Refactor workflow and is a pretty standard practice across all languages and frameworks.
With that dead simple explanation of how TDD works, let's discuss the importance of TDD and the best way to answer this coding interview question.
There's quite a bit of debate on the topic, with a number of prominent developers who are against the practice of TDD, with one of the main arguments being that many coders don't use it properly and are essentially just testing pre-existing functionality instead of behavior unique to the application.
However, with that being said, if you're looking to get hired as a developer there is a very good chance that you will need to be fully versed in how to work with TDD and BDD since I don't know of very many software organizations that don't require tests.
There are four main reasons why I use TDD for all the production applications that I build or manage:
- Regression: If you add a new feature into your application, you need to have 100% certainty that the new code you added won't break any pre-existing functionality in the app.
For example, if I create a new method that will break if any nil values are passed to it and I call that method on legacy data that could contain some nil values, I want to know that before the new feature goes live. Without tests, I'd have to go and manually test every part of the application each time I implement a new piece of functionality. However, if I have a full test suite I can simply run the tests, and if they're all passing it is a good indicator that the new changes can be pushed live.
- Team management: If you're managing a team, having a team of developers that follows TDD processes will give you a level of transparency into what they're doing. In fact, in Kent Beck's book Extreme Programming, Beck says that testing is one of the biggest keys for a development process to stay on track and budget.
- Documentation: When an application that was built with TDD is finished, the tests should be able to provide 100% of the documentation for the software. Certain testing frameworks, such as RSpec, even have the ability to print out tests in a documentation form that provides a full description on the app's behavior and can be understood even by non-technical individuals.
- Leads the development process: One of the most important keys to writing good software is to break code into as many small, manageable chunks as possible. When you use TDD you should naturally write small methods, efficient class definitions, and you should have minimal code bloat. When you're following TDD practices the tests themselves should lead the software's development, and the end result should be a well-organized and scalable code base.
One caveat to TDD is that testing is pointless if the test suite is not well structured. If you simply create a myriad of tests that do nothing more than test the core functionality of a language or framework, your test suite isn't going to have any benefit. However, if you build an application and let the tests drive your development and code structure, you will end up with a great application that you should be proud of.
For further information, I recommend reading the full series by Martin Fowler, which is seen as one of the most in-depth discussions on TDD ever produced.