Test Driven Development for Successful Code Deployment
Applications are written by humans. Humans are fallible by nature, therefore bugs can be unintentionally introduced. Developers strive to write good code, but may sometimes introduce bugs by not understanding what the requirements are, or by conducting poor testing, edge cases, etc. Bugs are inevitable.
To shield developers and organizations from the introduction of bugs in applications, developers can leverage Test Driven Development (TDD). TDD reduces the number of bugs introduced in applications, and more importantly creates a framework in which bugs are discovered before they reach the client.
In TDD, a requirement is split into small, easily-managed chunks. Tests are written to cover each of those small chunks, and code is implemented to ensure that tests are passed. With this approach, no new code is introduced outside of the requirements’ parameters, so that at the end of the development cycle the deliverable matches the requirements exactly. The tests ensure that the particular feature operates as designed, and that changes made to the code base for that particular feature do not interfere with other parts of the application, thus introducing more bugs.
One risk that may cause TDD to fail is implementing the feature first and then writing the tests to match it. The risk of this particular approach is that key components are overlooked and, in the worst case scenario, that tests are not written at all due to time or budget constraints.
A feature that has been tested only by the developer, the QA person, or the internal tester/user without the benefit of a fully flushed test scripts often will have bugs. Moreover, the interaction of the new feature with existing code could very well introduce more bugs. These bugs will have to be fixed, which in turn will require the allocation of extra resource hours and thus increase costs.
With TDD, more time is spent up front in the development stage, but a lot less time is spent later on fixing bugs. And if bugs do appear, they are mostly due to changes in the requirements or edge cases.
In PHP in particular, a developer can write tests with suites such as PHPUnit or Codeception and also enable code coverage. The testing suite will then highlight which parts of the code have been executed when the tests run. As a result, the developer will get a very good idea of what code has not been executed, and where problems with the testing exist.
With the coverage report, the developer can easily write more tests to cover the areas that have not been covered, or refactor the code by removing the parts that never executed. The coverage report can also identify optimization opportunities and logic errors.
The above allow the developer to ensure that the code stays DRY (Don’t Repeat Yourself), and that maintainability is kept at a high level.
TDD might appear labor intensive at first. However, the time to write tests diminishes over time as developers get used to the process and are able to appreciate its multiple benefits. In time, no code is written without tests, which should be the goal of every software company. Without testing, a developer cannot claim that the code quality of the feature that he or she is implementing is high.
Suggested Reading
