As with any programming, setting up a proper test environment can go a long way towards speeding up your development process. Testing Perl CGI programs is a lot like testing non-CGI programs, but there are some additional considerations.
If you are developing CGI programs for personal use, you first need to make sure that your ISP allows personal CGI programs, and if possible, you will shell access to the server where your programs will run, you often will not get CGI and shell access with a default user account since these features are not needed by the vast majority of Internet customers.
When testing from a browser, you will not see messages written to standard error in your browser, they will be directed to the web server error log, so you will need to be able to view the server error_log file during testing. If your ISP does not allow shell access to the web server, you will need to fully test your CGI programs on some other computer prior to uploading them. And even if you do this, it will make development more difficult since local environmental differences may cause errors on your ISP web server that did not occur on your own test server. If you do not have shell access to the server, your access to the error_log and access_log are likely to be limited either by policy, or just as a practical matter.
It is common for ISPs to not allow user written CGI programs due to the security concerns they raise. In fact, if you are writing a commercial application, hosted at an ISP, This kind of policy can for your own protection. If your application runs on a virtual server along with other web sites, you need to not only be concerned about security and reliability of your application code, but also with the security and reliability of the application code of the other sites on that same physical system. If you have a commercial application, you will need to make a decision if your product requires a dedicated server or not.
Other ISPs, like Siscom, allow user written CGI programs, but only on a separate server from their main web server. This allows them to ensure better security and reliability of the primary web server by isolating potentially risky CGIs. In the case of my CGI programs, this means that my static HTML and my CGIs live on different systems, and any links to CGIs from my static HTML must use fully qualified URLs rather than simply relative URIs in the link .
Whether you are developing CGI programs at an ISP, or at an in house server, it is good practice to have a separate development and production area.
This will allow you the freedom to break your programs while implementing new features without interrupting access. This can be either a physically separate server, or could be a different virtual server on the same system. Be aware however that when using virtual servers, misbehaving CGI programs could impact the reliability or security of your production virtual server in ways that developing static HTML would not.
While your CGI programs are under development, you want to prevent external access to the programs, otherwise software bugs and security holes could cause problems as programs before they are ready. If you are developing for personal use, it may be sufficient to use security through obscurity, that is just not publish links to your new scripts. But if you are developing for professional or public use, you may need to limit access via passwords, firewall rules, or use .htaccess files within Apache to limit access.
You will want to ensure that your test driver's environment is as close to the configuration of your production environment as possible. This includes things such as server and OS software versions, the path names to your programs, what, if any, extra Perl modules are installed, server configuration files, file and directory permissions.
Using relative path names and environment variables pointing containing path prefixes can help make it easier to move code and static HTML from test to production environments. This applies to both internal variables, and also to links placed in your static and dynamically created HTML.
The first time you run a new or modified program, it is a good idea to run it from the command line rather than from a browser. This will allow you to see the full text of error messages produced by the Perl interpreter in the case of syntax errors. It is also easier to spot and halt infinite loops or hung programs from the command line than it is when running programs via the browser.
Once you know that your program is syntactically correct, you may need to start passing environment variables to the program. You can do this simply by using "setenv" in csh, or "set/export" in sh, bash, ksh. You can use a program like the encode.cgi program that we discussed earlier to encode your QUERY_STRING.
To help out your testing, it can be handy to write test harness scripts that set environment variables prior to calling your CGI programs from the command line. These can also be used for easier regression testing of existing programs when you are making changes to existing programs. Like with any programming, you need to keep in mind that the effort maintain a program over time generally exceeds the effort needed to create the program in the first place.
Here is an example test harness to help set environment variables prior to calling your CGI program. Note that this is not a CGI program, but is a command line program that you use when testing CGI programs from the command line rather than from a browser.
In summary, here are some things to do that will make your testing easier. Note that many of these items are just good programming practices whether you are developing in CGI or for some other environment.
Copyright 2001 - Andy Welter