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)
Part 1 – Technical Background and Setup
Part 2 – Implementing Test-Driven Development in a PHP Project
Part 3 – Deployment Automation and Monitoring

Test coverage

It’s great having unit tests, but if we only test a few parts of the solution, then there’s more chance of breaking the code base unintentionally. Still, having a few unit tests is better than having no unit tests. I’m not aware of a solid industry standard number or percentage of ideal test code coverage. Some say 80% to 95% test coverage is good, but that depends on the project. I still believe that 50% test coverage is better than 0% test coverage, and every project can be very different. The test coverage can be configured to exclude some parts of the code base as well, so having 100% test coverage does not literally mean 100% of all code in the code base is covered by automated tests. Nonetheless, it’s still good to know how much test coverage we have for our solution. For developers who are just getting started with unit testing, it’s important to point out that having a few tests is better than not writing unit tests at all. Don...