Testing is an important part of software development. Whether we are aware of it or not, we conduct testing continuously. For example, when we write a class in PHP, we may debug it step by step or simply use
die statements to verify the implementation works according to our initial plan. In the case of a web application, we're entering some test data in forms to ensure the page interacts with us as expected.
The testing process could be automated so that each time when we need to verify something, we just need to call up the code that does it for us. The code that verifies the result matches what we've planned is called test and the process of its creation and further execution is known as automated testing, which is the main topic of these testing chapters.
Test-Driven Development (TDD) and Behavior-Driven Development (BDD) are approaches of developing software by describing behavior of a piece of code or the whole feature as a set of scenarios or tests before writing actual code and only then creating the implementation that allows these tests to pass verifying that intended behavior is achieved.
The process of developing a feature is the following:
After it's done the process is repeated again for another feature or improvement. If the existing feature is to be changed, tests should be changed as well.
Tip: If you feel that you are losing time doing a lot of small and simple iterations, try covering more by your test scenario so you do more before executing tests again. If you're debugging too much, try doing the opposite.
The reason to create tests before doing any implementation is that it allows us to focus on what we want to achieve and fully dive into "how to do it" afterwards. Usually it leads to better abstractions and easier test maintenance when it comes to feature adjustments or less coupled components.
So to sum up the pros of such an approach are the following:
In the long term it usually gives you a good time-saving effect.
Tip: If you want to know more about the principles for gathering software requirements and modeling the subject matter it's good to learn Domain Driven Development (DDD).
While the test first approach described above makes sense for long term and relatively complex projects it could be overkill for simpler ones. There are some indicators of when it's appropriate:
There's nothing wrong in creating tests covering behavior of existing implementation.
In some cases any form of automated testing could be overkill:
Still if you have time it's good to automate testing in these cases as well.
© 2008–2017 by Yii Software LLC
Licensed under the three clause BSD license.