Test Driven Development(TDD): From Principles to Code

Hi folks, In this blog post I am going to discuss another topic in Software Testing which is called Test Driven Development(TDD).

What is TDD?

It is a software development approach where tests are written before the actual code that needs to be implemented. The process typically follows a cycle of writing a test first, implementing the code to pass the test, and then refactoring the code if necessary. This is an iterative cycle that is carried out during the development process.

TDD Process

1. Write a Test:

• Write a test for functionality that has not been written yet.
• The test is written in advance of the actual code and is expected to fail initially since the corresponding functionality doesn’t exist yet.

2. Run Test Suite:

• The test is executed to confirm that it fails and is expected to fail initially since the corresponding functionality doesn’t exist yet.
• But, only the newly written test should fail and other older tests should be passed. If not, first figure out why other tests are failing and need to fix that problem.

3. Write Code:

• Write the minimum amount of code necessary to make the test pass without causing other tests to fail.

4. Run Test Suite:

• All tests, not just the newly added one, are executed to ensure that the new code didn’t break existing functionality.
• If any test fails, go back to step 3. If all tests pass, continue.

5. Refactor Code (if needed):

• Refactor the code to improve its structure, readability, or efficiency without changing its external behavior.

6. Run Test Suite:

• After refactoring, tests are run again to ensure everything still works as intended.
• If any test fails, go back to step 5. If all tests pass, continue.

6. Repeat:

• Steps 1–5 are repeated for each new functionality.
• If there is no more functionality to add, the application is complete!

Benefits of TDD

• Early Bug Detection: Issues are identified and addressed early in the development process when they are generally less costly to fix.
• Improved Code Quality: The focus on writing tests helps ensure that the code is modular, maintainable, and adheres to the specified requirements. Further, developers get a clear idea about the requirements and architecture.
• Regression Testing: The suite of tests created during TDD serves as a form of regression testing, allowing developers to catch regressions when making changes to the codebase.

Drawbacks of TDD

• Time-Consuming: Writing tests before writing the actual code can be time-consuming and TDD may seem like it slows down the development process.
• Not Suitable for All: TDD may not be the best fit for projects where requirements are unclear or rapidly changing. In such cases, writing tests before the requirements are well-defined can be challenging, and maintaining a large test suite can become challenging.

So applicability of TDD varies according to the project characteristics, team expertise, and organizational culture. Although TDD might not suit every scenario, many teams find it valuable when appropriately applied to projects with well-defined requirements and a stable development environment.

Ok. Hope you all got a clear idea about TDD and let’s move to a practical example of using TDD for a real-world scenario.

Use Case: Develop a small program that prompts a user to enter a password and checks the strength of the provided password using test-driven development.

The requirements are as follows:

1. A password must be at least 12 characters long and can ONLY include the following.

English alphabetic characters

→Uppercase English characters (‘A’ through ‘Z’)

→Lowercase English characters (‘a’ through ‘z’)

Numbers 0 through 9

Special characters: ~ ! @ # $ % ^ & * ( ) — _ = + [ ] { } \ | ; : ‘ “ , < > / ?.

2. The program must check the validity of the user password as follows:

If the user password does not match the above criteria the program must print the message “Invalid Password!” and exit immediately.

3. The program must further check the strength of the password as follows:

If the password is strong the program must print “Strong password” and exit with no further action.

If the password is not strong, the program must print “Weak password” and exist with no further action.

A user password is considered strong if ALL the following conditions apply

→ The password must be at least 14 characters long.

→ The password must use a combination of uppercase and lowercase characters.

→ The password must use a combination of numbers and special characters.

→ There must be at least 2 special characters.

→ There must be at least 6 alphabetic characters.

You can find my TDD solution for the above use case in the below video tutorial. (Tip: increase the playback speed if you are comfortable with the concepts)

You can find the complete source code from this GitHub URL.

Happy Coding and Testing !!👨‍💻🥳