Simply put, Test Driven Development are tests for code to pass. (Putting it simply does not exhibit the profound benefits it has while creating or recreating code. Test Driven Development is highly efficient in many ways.
TDD code is created prior to creating the program or software code. This alone has a great impact. Creating tests prior to the actual solution allows for extensive thought on the overall goals and intentions of the program. Breaking down each functionality and creating tests provides clarity on how to approach a certain challenge and makes the creation of a easier. These tests provide in the moment feedback on code for developers to analyze the functionality, or lack thereof.
So it is good to use TDD when creating the solution initially, but it is still beneficial in the future. For example, code needs to be refactored and simplified sometimes. Using TDD will allow the developer to refactor extensively, and still receive that feedback if part of the code or functionality fails. Furthermore, using test driven development it will provide longevity to your final product. With test solutions implemented, the product is easier to maintain and manage. It provides better structure and guides a developer to problematic code cutting down debugging time.
Some individuals are not crazy about TDD because it does take time to create tests, however, it is important to remember that your final product is not the final product. At some point or another, the product will be altered or edited. TDD allows the incorporation of new code a lot easier. Although some do not see the benefit in the time consumption on tests prior to driving a solution, some tests show that there is a 40% reduction in defect rate when using TDD, as stated by Brian Nielsen and Arne Skou in Test Driven Development (linked below).