What is TDD?
TDD stands for Test Driven Development. Typically when coding a program, a developer might think about the purpose of the program they are writing, think about what the code should do, write the code, then test if it works the way they expected. This is a more "traditional workflow" for software development. Test Driven Development is the process of deciding what you want your code to do, writing failing tests to specify functionality, then creating code to pass those tests. "In a nutshell, TDD changes our regular workflow" according to Peter Olson. By reversing the workflow in this way, and specifying the rules of the program's functionality first, a programmer will save a lot of time on debugging and ultimately write better code.
Why is TDD important?
Writing tests first can allow a developer to save time on debugging as well as many other benefits. According to Eric Elliott in his blog, TDD Changed My Life, "The point is not how long it takes to type this code. The point is how long it takes to debug it if something goes wrong." Note: Eric's blog is a great read which I recommend. (linked in sources below) He brings up several other good points and benefits to utilizing TDD rather than traditional development workflow. Utilizing TDD can allow easy separation of concerns, and testing sections or lines of an application separately, ultimately yielding better test coverage. Test Coverage refers to the amount of code covered by test cases. Having well-written effective tests before you code, can also help mitigate "fear of the merge button" or fear of change. If the code you've written essentially has the capability of testing itself before merging into production, there is less need to manually check and debug each piece before merging new code. If testing is well implemented it can be mostly automated and test coverage will be near 100%.
Types of Testing
Unit testing, refers to a self contained test or set of tests which focus on specific concepts or functionality. By writing unit tests for individual pieces of the program, debugging broken code becomes much easier to do. If a developer was only testing the application as a whole, utilizing End-to-End testing as an example, finding which pieces of code may or may not be broken would be very challenging. It is smart to utilize different testing methods to build an effective program. And allowing Tests to drive development can empower programmers to try new things, code with confidence, and build in checks and balances for merging new code.
Two types of testing to consider when talking about TDD would be Manual versus Automated testing. Manual Testing, according to Brandon Wozniewicz with Free Code Camp, is "the process of checking your application or code from the user's perspective." An example of this could be if you were building a YouTube look-alike, you might go to your rendered page in the browser and try using it like you would the actual YouTube site. If you are able to use the site as you expected then this manual test would be successful. Alternately, Automated Testing again according to Wozniewicz is "writing code that checks to see if other code works." In other words rather than relying on a user or yourself to test all the functionality of the YouTube look-alike, the criteria for the tests remain the same and allows for more and faster testing.
How To Write Tests
There are many tools and testing frameworks for utilizing TDD and other models like Behavior Driven Development. One non-tech analogy for TDD is the following example:
Using TDD does necessitate a deeper understanding of how the code should work and possibilities in development. In that way Elliott mentions, that there is a "learning curve" associated with using TDD well. Chai, Mocha, Jest, Jasmine and Karma are all common testing frameworks that allow a developer to more easily implement testing into their workflow. Each of theses has varying benefits and uses but ultimately, it is the responsibility of the developer to understand how to to implement tests into their program.
In conclusion, TDD requires some adjustment upfront from developers who are already used to coding from scratch. But by putting a bulk of the thinking work up front and preparing yourself as you go, ultimately it will yield better and tighter code.