1

What Is Test-Driven Development and Why Use It in PHP?

Developing web applications is fun and productive when using the PHP programming language. The learning curve to get started with PHP is relatively shallow, which is a very important trait of a programming language. There are a lot of open source learning materials, frameworks, packages, and full-blown extendable products backed by a very large open source community available for PHP developers. PHP is an enterprise-ready programming language and is widely used as a web-based solution to solve different business problems. Businesses and developers can quickly develop and deploy web applications with PHP. Once these businesses start to succeed and grow, they'll need more features, bug fixes, and improvements to be released on top of the original solution. This is where it starts to get interesting. Maintenance of commercially successful software can be one of the biggest contributing factors to the cost of the software, especially when it's not built to be easily maintainable or testable from the beginning. Implementing test-driven development (TDD) will improve the maintainability of the software and will help reduce the cost and time to market for a feature.

There's a problem that most of us developers might have already experienced or observed: a feature or a bug fix has been released and it has caused more problems, regressions, or unintended software behavior. If you are coming from a development environment where most or all the quality assurance (QA) tests are done manually post-, pre-, or even mid-development, then you might have experienced the issues that I have mentioned. This is where implementing TDD can really help. TDD not only helps in implementing automated tests but also guides or even forces us in a way to develop cleaner and more loosely coupled codes. TDD helps developers write and build tests before even writing a single feature code - this helps ensure that whenever a feature or solution code is being written, there will be a corresponding test already written for it. It also helps us developers stop saying "I'll add my unit tests later."

Before writing any codes, it's very important to understand what TDD is, and what it is not. There are some common misconceptions about TDD that we need to clear up to help us stay focused on what TDD really is. In this chapter, we will also try to use a very simple analogy and try to emphasize why we would want to implement TDD as a part of a software project.

In this chapter, we will be covering the following:

• What is TDD?
• Common misconceptions about TDD
• Why should we even consider TDD?
• What are we planning to achieve in this book?

What is TDD?

TDD is a simple way of developing software where we think about and define what needs to be the outcome of our programs before we start writing the actual codes that solve a problem.

TDD is a software development process where test cases are developed first before writing the actual code that solves a problem. The test cases will be written as PHP code that will use or call the solution code that developers will be building. The test case code that you build will trigger the development of the solution code that you will write to solve a problem.

From what I've seen, this literal description is what demotivates a lot of developers from applying this process. TDD is a process, and it's a way of thinking. It's not simply about writing unit tests.

The test program you write should always fail the first time you run it because you haven't built the programs the test needs to pass yet. Then, you will basically have to build the solution codes that the test program will use until the test program itself gets the expected results from your solution codes. Literally, the failing test will drive you to write the codes to pass the test - hence the term TDD. Maybe you can even call it failing-TDD. It's like saying "I wrote a test to fail my code, now I need to fix it."

In TDD, I can see four main reasons why it's important to write a failing test first. First, you will write a failing test and make sure your test framework application can recognize it. This ensures that your development environment is properly configured and you can run your test programs. Second, your failing test will help you define what solution or feature code you'd like to write, and what is expected for that test to pass. This will help you as a developer, in setting or focusing your mindset on the purpose of the feature code you are writing. Third, the failing tests you write will serve as reminders to know what other programs you need to complete. Fourth, writing your tests first will help ensure that your solution code is covered by automated tests.

By trying to make your solution code unit-testable, you are sometimes inadvertently making your codes less coupled - it's like a cycle. As you continue to write loosely coupled codes, you will notice that your codes will start to look more organized and less of a tangled mess. As you continue writing solution code following the TDD process, it will continuously help you spot where tight couplings are in your product, sometimes encouraging you to refactor and decouple your code just to make it unit-testable. There are software development principles that will help you further improve your codes, such as the Single-Responsibility Principle, which will be discussed more in Chapter 8, Using TDD with SOLID Principles.

Now that we have defined and have a brief understanding of what TDD is, let's go through some of the common misconceptions associated with it.

Common misconceptions about TDD

In this section, we'll look at some of the misconceptions that I have personally observed that developers have about TDD. Time and time again, I've encountered people who have a poor understanding of TDD. When I talk to some of them about why they're not a fan of TDD, they sometimes tell me reasons that are not even related to TDD.

Testing software is not my job as a developer; therefore, I don't need TDD

I have said this myself. I used to think that I just needed to churn out solution code as fast as possible, test a little bit manually, and let the testing department ensure that everything is built correctly. This is probably the worst misconception I've ever had about TDD. As software developers, we develop software as solutions to problems. If we developers are the ones causing more problems, then we are not doing our jobs.

Developing with TDD is unnecessarily slow

I would be surprised if this were the first time you are hearing this. I first heard this from a client who had a technical background, not from a developer. I wasn't a fan of TDD myself and willingly agreed with my client back then. Sure, it's slower to write test codes and solution codes together; I would have to type more characters on my keyboard, after all!

When working on enterprise projects, from what I have experienced, TDD is what saved us from months of bugs and regressions. Writing tests and having good test coverage, which is discussed in Chapter 5, Unit Testing, will help ensure that the next time someone else touches the code or adds new features, no regressions will be introduced. TDD will help you build a lot of automated tests, and running these tests is cheaper and quicker than handing over your untested solution code to a testing team or testing company for manual testing.

Writing automated or unit tests is TDD

TDD is not about writing automated tests or unit tests for existing functionalities. TDD is not about getting your QA department or getting a third-party company to write automated tests for existing software. This is the exact opposite of TDD.

The most common misconception I have observed is that some developers and testers assume that TDD has something to do with testers writing automated tests for the codes that the developers build. I believe that this is a very bad misconception. It's no different from developing a program and sending it to the QA department for manual testing.

Getting testers to write automated functional tests is a very good thing, especially for existing functionalities that do not have automated tests, but this should only be thought of as supplementary test coverage for software and not be confused with TDD.

TDD is a silver bullet

The last misconception that I have encountered is assuming that if we developers have built excellent test coverage by following TDD, we will no longer need input from the software development department and QA department or team. Time and time again, I've proven myself wrong, believing that code that's written via the TDD methodology is bulletproof. I am very fortunate to work with knowledgeable and skilled software engineers and test engineers. Code reviews are critical; always get your codes and test scenarios peer-reviewed. Edge-case tests and functional scenarios that...