Running PHPUnit in Windows Azure
Running PHPUnit in Windows Azure
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
In my last post I suggested 3 strategies for testing OSS/Azure applications. In this post, I’ll dive deeper into the first suggestion by showing you how to run unit tests (using PHPUnit) in Windows Azure. (I’ll assume that you have PHPUnit installed as a PEAR package.)
If you read my last post, you may recall that the first option I suggested was this:
RDP to staging instance and run command-line tests. This approach involves enabling RDP access to a deployment (I’m assuming deployment to a staging slot), opening a command prompt, and running your tests as (many of you) normally would.
After figuring out how to run PHPUnit from the command line in a Windows Azure instance, I did find that a bit more configuration work than I anticipated was necessary. I’m not 100% certain that this is the best way to run PHPUnit in Windows Azure, but it is one way. I’d be interested in hearing better ways to do this.
In any case, here are the steps…
1. Build your application. Build your application as you normally would, running your PHPUnit tests locally.
2. Package your application together with your custom PHP installation. Instructions for doing this are here: Packaging a Custom PHP Installation for Windows Azure. As I stated earlier, I’m assuming that you have PHPUnit installed as a PEAR package. If you followed the default installation of PEAR and PHPUnit, they will be included as part of your custom PHP installation.
Note: Before you actually create the package (i.e. step 7 in the tutorial above), be sure to first make the edits in the .csdef and .cscfg files outlined in the next step.
3. Enable RDP access to your Azure application. Instructions for doing this are here: Windows Azure Remote Desktop Connectivity for PHP Applications. Note that this step is actually part of the previous step as it requires that you edit your .csdef and .cscfg files prior to creating a package for deployment.
4. Deploy your application to staging. Instructions for doing this are here:
5. Login to an instance of your application and find your PHP installation. After you login to an instance of your application, you’ll need to find your application (you can’t be sure it will always be in the same location). I found mine here: E:\approot (and so my PHP installation was here: E:\approot\bin\PHP).
6. Add your PHP directory to the Path environment variable. This will allow you to run php.exe and phpunit from any directory.
7. Add PEAR to your include_path. Chances are that your PEAR installation is no longer in the include_path you had set up when running PHP on your local machine, so you’ll need to update it. In my case, I simply had to do this in my php.ini file:
include_path = ".;E:\approot\bin\PHP\pear"
8. Edit phpunit.bat. Again, chances are that your PHPUnit configuration used hard coded paths that will need to change in the Azure environment:
if "%PHPBIN%" == "" set PHPBIN=E:\approot\bin\PHP\php.exe
if not exist "%PHPBIN%" if "%PHP_PEAR_PHP_BIN%" neq "" goto USE_PEAR_PATH
"%PHPBIN%" "E:\approot\bin\PHP\phpunit" %*
9. Run your tests. Now you can open a command prompt, navigate to your application root directory, and run your tests.
Assuming all your tests pass and you are ready ready to move your application to production. One easy way to do this is through the Windows Azure Portal…all you have to do is select your deployment and click VIP Swap:
However, after you move your app to production, you will likely want to disable remote desktop access to all instances. You can do this by selecting your role and unchecking the Enable checkbox in the Remote Access section near the top of the portal web page:
If you wanted to be doubly sure that no one could remotely access your application, you could also remove the deployment certificate used for RDP access.
As I mentioned earlier, I’d be interested in hearing suggestions for improvements on this process.
Opinions expressed by DZone contributors are their own.