Test-driven development (TDD), also known as test-first development, is the process of developing and completing automated tests before the application’s actual development. Simply stated, TDD writes and corrects failed tests before starting to write new code. This assists developers in avoiding duplication of codes as they write a smaller amount of code at one time to pass the test successfully.
The purpose of test-driven development is simple: Make code that is clear, simple, and free of bugs. TDD for an application begins by developing and designing a test for each small functionality. It then instructs web developers to create new code only if an automated test fails. This minimizes or altogether avoids duplicate code.
An underlying assumption of test-driven development is that a testing framework will be available to you. For acceptance, you may use tools like RSpec or Fitnesse. Agile software developers will often use the xUnit family of open source tools like VbUnit or JUnit for developer TDD. Commercial tools are also available options. Without tools like these, test-driven development is nearly impossible.
Whether doing frontend web development, back end web development, or full-stack web development, test-driven development is an essential process for any web developer to know and understand. The award-winning professionals at Dom & Tom recognize the importance of TDD and are here to assist you with any questions you may have.
Stages of Test-Driven Development
Five necessary steps in the test-driven development cycle are continuously repeated during the software development process. These steps work to achieve the overall goal of TDD in ensuring code is efficient and straightforward while fulfilling the functional business requirements.
Step 1: Write a Test
Tests drive development, so creating a new test is an obvious first step. This test should be as simple and as succinct as possible, testing a particular component or aspect of a larger feature. For instance, if you are creating a feature for user registration, you could create a test encompassing each aspect of the registration process, from generating form elements, user entry, database connection, data models, and more. However, correctly creating a single test that effectively and efficiently encompasses all of these aspects from the outset would be extremely difficult.
Instead, TDD encourages developers to write the smallest test necessary to address the feature being actively developed. Over time, several tests will be created until enough testing exists to address each specific aspect of the larger overall feature.
Therefore, the single test relating to a user registration feature may be as simple as “Phone field isn’t blank.” Most TDD tests use some type of language-specific framework to allow tests to be “named” or “titled,” usually using a simple phrase defining desired behavior, also known as a user story. So this first test, titled “Phone field isn’t blank,” merely tests if the phone field is empty at form submission.
Step 2: Confirm the Test Fails
Once you create the test, you will need to confirm the test fails. Test-driven development methodology’s entire purpose is to force the developer to think about a section of code or a feature’s requirements. This means the test isn’t only necessary to confirm when the feature finally works as desired, but also that the test you are creating will fail before implementing that feature.
When you can confirm the new test fails, and for the specific reasons you expect, you can be confident the test is useful and beneficial in writing the necessary code to pass the test successfully.
Step 3: Write Code to Pass Test
Once you confirm the test fails, you must now write code that allows the test to pass. An important point to remember is not writing any extraneous or additional code that goes beyond the test’s scope. Just as you were focusing on creating the most straightforward possible test for Step 1, you will want to write the most straightforward possible code that allows the test to pass.
The code written during this step is usually rough and not in a finalized form. This is OK as the entire TDD process encourages you to refactor continually. This means your current code will likely change several times in the future.
Step 4: Confirm the Test Passes
With the new code written, you now need to confirm that the test passes. In the example, we confirmed that submitting a registration form with a blank telephone field results in our test failing, while placing text in the telephone field results in the test passing. This is all there is to the test-driven development process.
Step 5: Refactor
During the fifth and final step, you will take the time to locate any problem areas and focus on simplifying the codebase. While you have a test that passes, the code writing process of allowing this test to pass may have resulted in some inconsistencies or duplications. This is to be expected and perfectly normal.
You should also frequently be rerunning all previous tests during this step to confirm you haven’t accidentally changed anything to cause a previously passing test to fail or introduce additional bugs. Many web developers know this practice of confirming functional codes isn’t breaking due to new changes as regression testing.