CMS and E-commerce

Testing

Testing your Web site isn’t a one-time, standalone step, but rather something you’ll need to do often. You cannot test your site too much! Unfortunately, it’s hard for the site developer to perform a truly good test of the site: He or she
created it, so he or she knows how it should work and uses it accordingly.

A better test is what happens when your family, coworkers, and annoying friends give the site a whirl. And I specify the annoying friends, because they’re the ones who will attempt to do things you never would have imagined. When these people, who aren’t Web developers themselves, purposefully or accidentally misuse the site, what happens? From these experiences you can improve the user interface and security of the whole application.

Improving those two things will go a long way toward a successful e-commerce venture. Still, there are steps you can take to effectively test your site yourself.

Relatively new to PHP is the concept of test-driven development and unit testing:
You define concrete and atomic tests of your code, and then run the tests to confirm the results. Each test should be concise and clear. As you write more code, you define more tests and continue to check each test to ensure that what you just did didn’t break any other functionality. Test-driven development and unit testing are big enough subjects that I recommend you research both further on your own, when you’re ready.

First, if the database or PHP is caching the results of a database query, then that query will not need to be executed with each request. Second, by default, each request of a PHP script requires that the PHP code be executed as if it had never been run before. By applying an opcode cache such as the Alternative PHP Cache, the PHP code itself is cached by the system, making that execution faster.

Finally, the end result is that HTML is sent to the Web browser. If you can cache the dynamically generated HTML, then no PHP code will be executed at all, no database queries are required, and the request itself becomes as fast as a request for a static HTML page.

Bottlenecks usually occur when PHP interacts with the file system, whether that means literal files on the server (like reading and writing text files or using sessions) or through the database application. I caution you against spending too much time worrying about profiling individual sections of code, because the improvements you can make that way will be relatively minor and possibly not worth your time. Better to learn good programming habits so that you don’t have to worry about profiling after the fact.