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

Summary

In this chapter, we’ve gone through the SOLID principles one by one. We used our tests to kickstart the development of our solution code so that we can use them as examples for implementing the SOLID principles in real life.

We have covered the SRP, which helped us make a PHP class’s responsibility or capability more focused. The OCP helped us avoid the need for touching or modifying a class in some instances when we want to change its behavior. The LSP helped us be stricter about the behavior of an interface, making it easier for us to switch concrete objects implementing that interface without breaking the parent class’s behavior. The ISP helped us make the responsibility of an interface more focused – classes that implement this interface will no longer have empty methods just because they were declared by the interface. The DIP helped us quickly test our ToyCarCreator class even without creating a concrete implementation of its dependencies...