Authorization
An Introduction to the Art of Unit Testing in PHP
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 )
Web App Trends: Users as Developers
The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.
It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.
But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).
Scratching Your Own Itch
The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.
“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”
“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”
( Read more )
It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.
But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).
Scratching Your Own Itch
The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.
“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”
“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”
( Read more )
Too Many Bits for DDMS
If you’re like me, you do your Android development outside Eclipse and therefore rely upon the full range of the Android toolkit, from activitycreator through DDMS. And, if you’re like me, you just plopped a 64-bit Linux (Ubuntu 8.10 “Intrepid Ibex”) on a multi-core PC for development work.
Which means, if you’re like me, you ran into a problem trying to get DDMS to run.
DDMS appears to be written using the Eclipse’s SWT GUI toolkit. The version of the SWT that ships with Android 1.0r2 is written for a 32-bit Java runtime. If you try running it on a 64-bit Java VM, you get a nasty error like “wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)” coming out of one of the RCP libraries (tools/lib/libswt-pi-gtk-3236.so).
I am sure there are any number of elegant ways to get around this that allow DDMS to run as 32-bit Java while the rest of your environment is 64-bit Java. However, I couldn’t find any. So, here’s a brute-force way to do it.
First, you need a 32-bit Java runtime. In Debian/Ubuntu, this is in the ia32-java-6-sun package. Install that using your favorite packaging tool (Synaptic, aptitude, apt-get, etc.).
You can then use update-java-alternatives –list to confirm that your 64-bit JDK is there, but the 32-bit JRE is also available. It should also have left alone your default Java (the one invoked when you run java at the command line).
Next, you need to teach DDMS to use the 32-bit Java instead of the default. Use update-java-alternatives –list to determine the path to your 32-bit Java runtime (e.g., /usr/lib/jvm/ia32-java-6-sun/bin/java). Then, make a copy of tools/ddms from your Android runtime and modify it, changing the value of java_cmd to match your 32-bit JRE location (e.g., java_cmd=”/usr/lib/jvm/ia32-java-6-sun/bin/java”).
Try it out, and DDMS should fire up just fine. Since it coordinates with devices and emulators using sockets or USB drivers, the fact that it is 32-bit does not affect its ability to interoperate with your other tools.
Of course, you have to remember to use your modified DDMS (e.g., set up a launcher for it on your desktop or a GNOME panel). And, you may need to repeat these steps, or ones like them, in future Android SDK releases, until DDMS is shipped in a way that works out of the box for both 32-bit and 64-bit Java.
Have a cleaner way to fix this problem? Post a comment and let us know!
Which means, if you’re like me, you ran into a problem trying to get DDMS to run.
DDMS appears to be written using the Eclipse’s SWT GUI toolkit. The version of the SWT that ships with Android 1.0r2 is written for a 32-bit Java runtime. If you try running it on a 64-bit Java VM, you get a nasty error like “wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)” coming out of one of the RCP libraries (tools/lib/libswt-pi-gtk-3236.so).
I am sure there are any number of elegant ways to get around this that allow DDMS to run as 32-bit Java while the rest of your environment is 64-bit Java. However, I couldn’t find any. So, here’s a brute-force way to do it.
First, you need a 32-bit Java runtime. In Debian/Ubuntu, this is in the ia32-java-6-sun package. Install that using your favorite packaging tool (Synaptic, aptitude, apt-get, etc.).
You can then use update-java-alternatives –list to confirm that your 64-bit JDK is there, but the 32-bit JRE is also available. It should also have left alone your default Java (the one invoked when you run java at the command line).
Next, you need to teach DDMS to use the 32-bit Java instead of the default. Use update-java-alternatives –list to determine the path to your 32-bit Java runtime (e.g., /usr/lib/jvm/ia32-java-6-sun/bin/java). Then, make a copy of tools/ddms from your Android runtime and modify it, changing the value of java_cmd to match your 32-bit JRE location (e.g., java_cmd=”/usr/lib/jvm/ia32-java-6-sun/bin/java”).
Try it out, and DDMS should fire up just fine. Since it coordinates with devices and emulators using sockets or USB drivers, the fact that it is 32-bit does not affect its ability to interoperate with your other tools.
Of course, you have to remember to use your modified DDMS (e.g., set up a launcher for it on your desktop or a GNOME panel). And, you may need to repeat these steps, or ones like them, in future Android SDK releases, until DDMS is shipped in a way that works out of the box for both 32-bit and 64-bit Java.
Have a cleaner way to fix this problem? Post a comment and let us know!
QuickOffice For Android Revealed
QuickOffice have revealed a version of it’s Microsoft Office editing software for the Android platform.
QuickOffice for Android will allow users to edit various Microsoft Office documents including Word, Excel and Powerpoint.
Thanks to a partnership QuickOffice and SoonR (a company providing remote-access technology), users will also have the ability to access documents on home PC systems via the internet.
Here’s some screenshots from the QuickOffice for Android software
( Read more )
QuickOffice for Android will allow users to edit various Microsoft Office documents including Word, Excel and Powerpoint.
Thanks to a partnership QuickOffice and SoonR (a company providing remote-access technology), users will also have the ability to access documents on home PC systems via the internet.
Here’s some screenshots from the QuickOffice for Android software
( Read more )
G1 and Cupcake - What
Current G1 owners are licking their chops at the prospect of getting some much desired updates to their Android phones. Features like video recording, stereo Bluetooth, and an on-screen keyboard are the only things missing from an otherwise robust OS. But will the G1 ever see the icing from cupcake’s features? Ask around and you’re likely to get varying answers.
Here’s what we’ve pieced together so far.
Cupcake is a different version, or image of Android. Carriers and handset makers are free to take whatever is available from Android and bend it to their liking. If the hardware you have doesn’t support stereo Bluetooth, then obviously the device won’t either. No software is going to override the hardware and get it to do something it can’t.
( Read more )
Here’s what we’ve pieced together so far.
Cupcake is a different version, or image of Android. Carriers and handset makers are free to take whatever is available from Android and bend it to their liking. If the hardware you have doesn’t support stereo Bluetooth, then obviously the device won’t either. No software is going to override the hardware and get it to do something it can’t.
( Read more )
Dataviz Bringing Microsoft Office to Android
This is great news! DataViz, makers of the uber-popular and uber-good suite, Documents To Go is bringing their award winning mobileOffice suite to Android! So if you’re a productivity beast or heavy business user, there’s one more reason to test out Android! You’ll have access to Microsoft Word, Excel, Powerpoint and PDF files on the go with Documents To Go. We’ve heard nothing but good things from Documents To Go so be ready to download their software in 2009!
Also, DataViz is bringing their Microsoft Exchange ActiveSync client RoadSync to Android as well, so users of Exchange take note! Everything is expected to release in 2009, which coincides with Android Market being capable of paid applications. We don’t know exact pricing yet, but one can expect a price near $29.99–a price that’ll surely be worth it for any heavy business user.
Also, DataViz is bringing their Microsoft Exchange ActiveSync client RoadSync to Android as well, so users of Exchange take note! Everything is expected to release in 2009, which coincides with Android Market being capable of paid applications. We don’t know exact pricing yet, but one can expect a price near $29.99–a price that’ll surely be worth it for any heavy business user.