Test Driven Development (TDD)

Test-driven development is a highly popular technique among developers. The idea is simple. Write tests first, and code the solution second. Typically, developers may think that they should code an application first and then write tests. TDD flips things around. In TDD, you:

1. Write a Test: First, you write a simple test for a small piece of functionality that doesn't exist yet.
2. See It Fail: You run the test, and it fails because you haven't written the code for that functionality.
3. Write the Code: Now, you write the actual code to make the test pass.
4. Run the Test Again: You run the test again, and if you've written the code correctly, it passes.
5. Refactor: If necessary, you clean up the code, making it neater without changing what it does.

This cycle repeats for each small piece of functionality, ensuring that everything you build works correctly.

Why TDD?

Test-Driven Development (TDD) might seem a bit unusual at first, especially the idea of writing tests before the actual code. However, there are several compelling reasons to use TDD:

• Writing tests first helps you think about what you want the code to do before you write it, leading to clearer, more focused code.
• When a test fails, you know exactly what part of the code is not working, so it's easier to find and fix bugs.
• If you want to change the code later (known as refactoring), having tests ensures that you don't accidentally break something that was working before.
• Tests act like a clear specification for the code. This means that if someone else works on the code, they can understand what it's supposed to do and make sure it continues to do that.
• Although writing tests takes time initially, it can speed up development overall by catching errors early and minimizing the time spent on debugging.

TDD essentially acts as a safety net, guiding development, catching mistakes early, and giving developers the confidence to change and improve the code. It fosters a development process that is more deliberate and reflective, where every step is validated against clear criteria, leading to robust and reliable software.

Downsides

While Test-Driven Development (TDD) offers many benefits, it's not without drawbacks or criticisms. Here's a look at some of the disadvantages and arguments against using TDD:

• There's a risk of focusing too much on writing tests and neglecting other important aspects of development, such as architecture and design.
• If the tests are not well-written or thorough, they may not cover all possible scenarios or edge cases. This can lead to a false sense of security.
• Writing tests for highly complex systems or functionalities can be challenging. Some argue that TDD is less suitable for certain types of applications, such as those involving complex user interfaces or intricate algorithms.
• As the codebase grows, maintaining a large suite of tests can become burdensome. Changes to code might require corresponding changes to many tests, increasing the maintenance effort.
• Not a silver bullet. TDD doesn't automatically ensure high-quality code. Poorly written tests or an incorrect understanding of requirements can still lead to faulty code.

While these disadvantages and criticisms are worth considering, many proponents of TDD argue that with proper understanding, training, and implementation, many of these challenges can be mitigated or overcome. The decision to adopt TDD should be based on careful consideration of the specific needs, goals, and context of the project and development team.

Regardless of where you stand, let's try looking at how TDD is done.

Setting up a Testing Environment

Test-driven development can be applied to any framework or tool. For this demonstration, we're going to use PHPUnit. If you haven't already, check out this lesson we did on unit testing.

To quickly set up an environment, follow these steps:

1. Install PHPUnit with the composer require --dev phpunit/phpunit command.
2. Create a directory called tests.
3. Create a file inside this directory called TestUser.php.
4. Add the following code:

use PHPUnit\Framework\TestCase;
 
class UserTest extends TestCase
{
  public function testMyTest(): void
  {
    $this->assertTrue(true);
  }
}

5. We're writing a test to make sure everything is working. The assertTrue() method checks if a given value is true. In this case, the test should always pass since we're passing along true. We can run the test with the ./vendor/bin/phpunit --verbose tests command.

Writing a Failing Test

The first step is to write a failing test. For this example, let's say our goal was to create a class for users that can perform greetings. Therefore, our test should be able to instantiate this class and then call a method to perform the greeting. We'll test the value returned by the method.

Since the method is supposed to return a greeting containing the user's name, we'll write a test to check that behavior. Inside the UserTest class, add the following method:

public function testGreet()
{
  $user = new User('John');
  $this->assertIsString($user->greet());
  $this->assertStringContainsStringIgnoringCase(
    'John', $user->greet()
  );
  $this->assertEquals("Hi! My name is John.", $user->greet());
}

Run the Test and See It Fail

At this point, if the User class hasn't been implemented or if there's a mistake in its implementation, the test will fail. If we were to run the ./vendor/bin/phpunit --verbose tests command, the test would fail.

Since you provided the implementation, assuming the code is correct, the test should pass. However, if there were any mistakes, this step would highlight them.

Write the Code to Make the Test Pass

Based on the test, we can assume a few things.

1. The name of the class is called User.
2. The User class must accept a string and store the string as a property.
3. The greet() method must return a string.
4. The greet() method must contain the name passed into the constructor method.
5. The format must be "Hi! My name is X." where X is the name.

Based on this information, our class would do something like this:

class User
{
  public function __construct(public string $name)
  {
  }
 
  public function greet(): string
  {
    return "Hi! My name is " . $this->name . ".";
  }
}

Run the Test Again

After creating the class, you'll run the test again, and if the User class is implemented correctly, it should now pass.

Refactor If Necessary

If you see any opportunities to make the code cleaner or more efficient without changing its behavior, you will make those changes now. After refactoring, you would run the tests again to ensure that everything still works as expected.

Rinse and Repeat

You would follow this cycle again for any other methods or behaviors you want to test within the User class or other parts of your application.

Overall, TDD provides a structured approach to development, using tests as a roadmap. By starting with the test and working towards making it pass, you ensure that your code meets the defined requirements and that each part has been carefully considered and verified. The ongoing cycle of testing, coding, and refactoring leads to robust, well-designed software.

Key Takeaways

• TDD is a development practice where you write tests before writing the corresponding code.
• The TDD cycle process involves writing a failing test, making it pass by writing or modifying code, and then refactoring. This cycle is repeated for each piece of functionality.
• TDD helps in writing more focused and clear code, which leads to improved code quality.
• Some challenges and criticisms of TDD include the initial time investment, learning curve, potential overemphasis on testing, maintenance overhead, and suitability for complex systems.
• TDD aligns well with Agile development methodologies, emphasizing iterative development and continuous validation of code.