Introduction
Testing is an essential aspect of developing in any programming language. If you don't test your source code then how can you verify it works as expected? Manual testing can only be performed irregularly and usually only in limited ways. The answer to testing source code regularly, and in depth, is to write automated tests which can be frequently executed. In PHP such tests are usually written using a unit testing framework, a framework which allows the source code of any application or library to be tested as isolated units of functionality such as a single class or method. As unit testing has gained popularity, it has become a standard practice in PHP with libraries and frameworks such as Swiftmailer, the Zend Framework and Symfony all requiring unit test coverage of their source code.
Unit Testing is often seen as an arcane, time consuming task — which it sometimes can be! But the point of spending time writing tests is to improve the quality of your source code so it has fewer overall bugs, many of which are detected early, a continual testing process to prevent new changes from changing the behaviour of older code, and to provide confidence that your code can be depended on. There are other benefits too, and we'll detail these later.
The Testing Fallacies
Unit Testing, and actually all other forms of testing, fall afoul of four common excuses which hinder adoption by developers.
1. It's time consuming and takes too long.
2. Complex code cannot be tested.
3. So long as it works, I don't need to write tests.
4. Testing is boring.
These are testing fallacies, excuses which appear quite reasonable but are actually misinformed in subtle ways. So let's clear up a few things!
Testing does take time. The question is why should that time be considered worthwhile and the answer is that it reduces the future time you would consume in modifying code, maintainance, refactoring and fixing undetected bugs. And we both know there would be tons of undetected bugs if you're not testing comprehensively!
Testing early is like catching the proverbial worm; as you write code, you can use Unit Tests to test isolated methods/classes or groups of functional classes immediately. By doing so you find and fix bugs quickly as they are created. A problem is that you find bugs so often, and fix them so quickly, that you barely notice the time it took. When you make changes later, and a test fails, you can fix the integration problem just as quickly — more saved time you barely notice. The benefits can be so well disguised you may miss them completely — and only see the test code it took you a few hours to write, not the bugs you solved in 10 seconds that would have taken minutes or hours six months down the line.
Secondly, there's complex code — and there's complex code made up of smaller practical parts. In OOP a simple objective is often «being testable». It's like a litmus test for quality decoupled code. If your code can't be easily tested than it's not that Unit Testing has failed, it's that you failed to write practical code which was flexible and decoupled. If you were testing as you wrote code, you would have been forced to decouple classes almost on automatic. The fact code seems too complex to test is usually a symptom of having waited too long to start testing!
Thirdly, working code and working tested code are two different animals. Tests offer a safety net which makes changes, refactoring, and new features less of a pain to add since integration issues will be detected almost immediately. They also improve the efficiency of new programmers on your team who, unfamiliar with the code, see their mistakes detected immediately by the shorter feedback loop and so gain experience on the run.
( Read more... )
Testing is an essential aspect of developing in any programming language. If you don't test your source code then how can you verify it works as expected? Manual testing can only be performed irregularly and usually only in limited ways. The answer to testing source code regularly, and in depth, is to write automated tests which can be frequently executed. In PHP such tests are usually written using a unit testing framework, a framework which allows the source code of any application or library to be tested as isolated units of functionality such as a single class or method. As unit testing has gained popularity, it has become a standard practice in PHP with libraries and frameworks such as Swiftmailer, the Zend Framework and Symfony all requiring unit test coverage of their source code.
Unit Testing is often seen as an arcane, time consuming task — which it sometimes can be! But the point of spending time writing tests is to improve the quality of your source code so it has fewer overall bugs, many of which are detected early, a continual testing process to prevent new changes from changing the behaviour of older code, and to provide confidence that your code can be depended on. There are other benefits too, and we'll detail these later.
The Testing Fallacies
Unit Testing, and actually all other forms of testing, fall afoul of four common excuses which hinder adoption by developers.
1. It's time consuming and takes too long.
2. Complex code cannot be tested.
3. So long as it works, I don't need to write tests.
4. Testing is boring.
These are testing fallacies, excuses which appear quite reasonable but are actually misinformed in subtle ways. So let's clear up a few things!
Testing does take time. The question is why should that time be considered worthwhile and the answer is that it reduces the future time you would consume in modifying code, maintainance, refactoring and fixing undetected bugs. And we both know there would be tons of undetected bugs if you're not testing comprehensively!
Testing early is like catching the proverbial worm; as you write code, you can use Unit Tests to test isolated methods/classes or groups of functional classes immediately. By doing so you find and fix bugs quickly as they are created. A problem is that you find bugs so often, and fix them so quickly, that you barely notice the time it took. When you make changes later, and a test fails, you can fix the integration problem just as quickly — more saved time you barely notice. The benefits can be so well disguised you may miss them completely — and only see the test code it took you a few hours to write, not the bugs you solved in 10 seconds that would have taken minutes or hours six months down the line.
Secondly, there's complex code — and there's complex code made up of smaller practical parts. In OOP a simple objective is often «being testable». It's like a litmus test for quality decoupled code. If your code can't be easily tested than it's not that Unit Testing has failed, it's that you failed to write practical code which was flexible and decoupled. If you were testing as you wrote code, you would have been forced to decouple classes almost on automatic. The fact code seems too complex to test is usually a symptom of having waited too long to start testing!
Thirdly, working code and working tested code are two different animals. Tests offer a safety net which makes changes, refactoring, and new features less of a pain to add since integration issues will be detected almost immediately. They also improve the efficiency of new programmers on your team who, unfamiliar with the code, see their mistakes detected immediately by the shorter feedback loop and so gain experience on the run.
( Read more... )
- —
- 14 May 2009 06:53
-
- leave comment
I made a tongue-in-cheek comment in another question thread calling PHP a terrible language and it got down-voted like crazy. Apparently there are lots of people here who love PHP.
So I'm genuinely curious. What am I missing? Why makes PHP a good language?
Here are my reasons for disliking it:
PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design.
The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.
A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!
Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!
( Read more... )
So I'm genuinely curious. What am I missing? Why makes PHP a good language?
Here are my reasons for disliking it:
PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design.
The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.
A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!
Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!
( Read more... )
PHP Speedy is a script that you can install on your web server to automatically speed up the download time of your web pages. Here’s an example, from a test page:
Before PHP Speedy — 14 requests that took 4.44 seconds
After PHP Speedy — 4 requests that took 1.1 seconds
PHP Speedy automatically joined together all the appropriate files and compressed them, greatly reducing the load time of the page. Let’s see what Yahoo’s Y-Slow makes of this:
Before PHP Speedy — Grade F (44)
After PHP Speedy — Grade A (96)
You can have a look at the test page for yourself:
Test page without compression
Test page with compression
Download
You can download PHP Speedy from this link: PHP Speedy 0.5.2 download
Installation — via auto-install
( Read more... )
Before PHP Speedy — 14 requests that took 4.44 seconds
After PHP Speedy — 4 requests that took 1.1 seconds
PHP Speedy automatically joined together all the appropriate files and compressed them, greatly reducing the load time of the page. Let’s see what Yahoo’s Y-Slow makes of this:
Before PHP Speedy — Grade F (44)
After PHP Speedy — Grade A (96)
You can have a look at the test page for yourself:
Test page without compression
Test page with compression
Download
You can download PHP Speedy from this link: PHP Speedy 0.5.2 download
Installation — via auto-install
( Read more... )
After reading an article some time ago entitled “40 Tips for optimizing your php Code” (and some others that are suspiciously similar), I decided to redo it, but properly this time with more accurate tips, providing references and citations for each and every one.
The result is this list of over 50 PHP optimisation tips…
Update: The list is more like 50+ PHP tips and tricks these days.
Enjoy!
( Read more... )
The result is this list of over 50 PHP optimisation tips…
Update: The list is more like 50+ PHP tips and tricks these days.
Enjoy!
( Read more... )
- —
- 15 March 2009 07:57
-
- leave comment
