Book Image

Test-Driven Development with PHP 8

By : Rainier Sarabia
Book Image

Test-Driven Development with PHP 8

By: Rainier Sarabia

Overview of this book

PHP web developers end up building complex enterprise projects without prior experience in test-driven and behavior-driven development which results in software that’s complex and difficult to maintain. This step-by-step guide helps you manage the complexities of large-scale web applications. It takes you through the processes of working on a project, starting from understanding business requirements and translating them into actual maintainable software, to automated deployments. You’ll learn how to break down business requirements into workable and actionable lists using Jira. Using those organized lists of business requirements, you’ll understand how to implement behavior-driven development (BDD) and test-driven development (TDD) to start writing maintainable PHP code. You’ll explore how to use the automated tests to help you stop introducing regressions to an application each time you release code by using continuous integration. By the end of this book, you’ll have learned how to start a PHP project, break down the requirements, build test scenarios and automated tests, and write more testable and maintainable PHP code. By learning these processes, you’ll be able to develop more maintainable, and reliable enterprise PHP applications.
Table of Contents (17 chapters)
1
Part 1 – Technical Background and Setup
6
Part 2 – Implementing Test-Driven Development in a PHP Project
11
Part 3 – Deployment Automation and Monitoring

TDD with the Single-Responsibility Principle

Let’s start with what I think is one of the most important principles in the SOLID principles. Are you familiar with god classes or objects – where one class can do almost everything? A single class for login, registration, displaying registered users, and so on? If there are two developers working on the same god class, can you already imagine how challenging that can be? And what happens after you deploy it to production and then an issue is found in the part where you display a list of registered users? You will have to change or fix that god class, but now the same class for login and registration has been modified and these processes may be compromised too. You run a bigger risk of introducing regressions to your login and registration functionalities by just trying to fix the list of registered users. You fix one feature, and there’s a greater risk of breaking other features.

This is where the SRP will start...