This book has been written with the intention of teaching how to use Codeception in conjunction with Yii 2. By using these two great frameworks, I confirmed that testing could finally become something that anyone would appreciate doing, rather than considering it an odd and not particularly clear appendix of development.
For this reason, this first chapter tries to address several aspects that are rarely touched on but hopefully should give you the understanding and required push to learn and adopt testing, and, on a larger scale, promote testing as a way to improve development as a methodology.
In this chapter, you will see the reason for testing and why testing should be planned into a project, and not done as an afterthought.
You will also see what will happen when you start testing: the implicit and explicit benefits for the short and long term, such as a change of mentality toward testing, the ability to improve component specifications, and architectural, design, and implementation choices, as well as refactoring, redistribution, and overall quality of code.
In order to explain why testing is so important, I'll also briefly dive into the organizational part of the process where Test Driven Development (TDD) and Behavior Driven Development (BDD) will be explained in relation to modern project management techniques, such as Agile and XP in a multi-skilled, self-organized team.
You will also see how the whole team environment can be improved and re-organized to help share knowledge and speed up workflow.
This chapter has been divided into the following three sections:
- Understanding the importance of testing
- Involving project management
- Obtaining the testing mindset
Since I started getting into quality assurance and testing in a professional way, I've never faced myself with the question of "what is testing?"
I have to be honest, but during my time at university, testing wasn't part of any course. I don't really know if this has changed recently, nor if what's being taught is of any importance or relevance to the business world.
In this book, I've tried to combine the practicality of development and testing using a great PHP framework, Yii at its version 2, and the testing suite of Codeception. I will present each topic with a keen eye on the actual benefit for the team, while showing from a higher perspective the planning and the organization of the work. Throughout the chapters in this book, I'll shift back and forth, trying to give a clear understanding of the details you will be working on and the scope of the work, the overall aim from a testing perspective.
But, before we venture into this journey, what effectively is testing? Google engineering director James Whittaker's words make a very good answer to that:
"Although it is true that quality cannot be tested in, it is equally evident that without testing, it is impossible to develop anything of quality."
There are aspects of testing that are so completely fused with development that the two end up being practically indistinguishable from each other, and at other times it is so independent that developers are not even aware that this is happening.
In the whole project lifespan, you start with ideas and transform them into features or stories, breaking them down into tasks. From there you move into the execution of each of these tasks that will hopefully grant you, at the end of them all, a finished product.
At any point in our development process, we have tried to put some level of quality in it, either by "checking" the page loaded or by doing some more smart and deep, if not automated, testing.
Atlassian's QA team lead Penny Wyatt points out that teams where quality assurance was not performed or left alone to perform small automation tasks, with unit tests for instance, had the highest story rejection rate, which is when a story will have to be re-opened after being completed because of wrong or missing functionality. We are talking about a 100 percent of rejection rate.
When such a situation occurs, we are left in a state where we have to go back into development and fix what we've done. This is not the only case: together with it, late discovered bugs and defects, and fixing them, are possibly some of the most expensive tasks in software development. In most cases, it has been shown that their cost is also way higher than it would have been to prevent them in the first place. Unfortunately, software development is rarely devoid of defects, and this should always be kept in mind.
As developers and managers, one of the goals we should have is to reduce the occurrence of defects to an economically acceptable level, and doing this also reduces the resulting risk associated with it.
As a practical example, a large website might have thousands of software errors but still be economically viable due to the fact that 99 percent of the website is displayed correctly. For a Falcon rocket or a Formula 1 car, a defect rate that high is not acceptable: the risk of having a single one in the wrong place might also cost the lives of people.
The other implicit aim for defect reduction is an investment in teamwork. An error introduced by one developer can have a ripple effect on the work of other team members and, overall, trust in the code base and other colleagues' work. In this chapter, and the later chapters, we are going to discuss this aspect in more detail by introducing some concepts of project management and how it can cooperate in ensuring that quality is ensured on many levels.
The last and possibly an equally important aspect is how testing can be used to document the code by example. This is rarely discussed or brought to the attention of developers, but we will see how tests can describe the functionality of our implementations in a way more precise manner than what PHP documentation comments can provide. I'm not saying documentation comments are useless, quite the contrary: in modern integrated development environments (IDE) such as NetBeans or PHPStorm, auto-completion and code hinting are a great way to improve the time to discover the underlying framework without having the need to search through a reference manual. Tests can and should in fact provide the much needed help a developer might need when trying to combine and use yet unknown interfaces.
When working with open source software that is a result of the work of a small self-organized team, having the ability to provide documentation without an extensive effort might be the key to rapid and continuous delivery.
But how do we ensure a delivery can be met within constraints that are imposed on the team? In order to explain this, we will have to take a quick detour into project management, from where some of the practices that are discussed and used in this book have been originating.