<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Language" content="en-us" /> <meta name="ROBOTS" content="ALL" /> <meta http-equiv="imagetoolbar" content="no" /> <meta name="MSSmartTagsPreventParsing" content="true" /> <meta name="Keywords" content="cherokee web server httpd http" /> <meta name="Description" content="Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration by reading files or strings, TLS/SSL (via GNUTLS or OpenSSL), virtual hosts, authentication, cache friendly features, PHP, custom error management, and much more." /> <link href="media/css/cherokee_doc.css" rel="stylesheet" type="text/css" media="all" /> </head> <body> <h2 id="_a_href_index_html_index_a_8594_a_href_dev_html_development_info_a"><a href="index.html">Index</a> → <a href="dev.html">Development info</a></h2> <div class="sectionbody"> </div> <h2 id="_development_quality_assurance">Development: Quality Assurance</h2> <div class="sectionbody"> <div class="paragraph"><p>Cherokee has an automated battery of scripts intended to prevent regressions.</p></div> <div class="paragraph"><p>You should run all the QA tests before whenever you implement changes to the code base. Not only will this catch most simple errors and prevent regressions from appearing. It will also help you a lot in your development process.</p></div> <div class="paragraph"><p>Everything is located under the <tt>/qa</tt> directory, so have a look there. This will display all the parameters that you can use with Cherokee’s QA test suit:</p></div> <div class="listingblock"> <div class="content"> <pre><tt> cd qa ./run-tests.py --help</tt></pre> </div></div> <div class="paragraph"><p>You can use it to run all the tests, or the specific ones you want.</p></div> <div class="listingblock"> <div class="content"> <pre><tt> ./run-tests.py</tt></pre> </div></div> <div class="paragraph"><p>Not only that. The full QA bench can be run through a Cherokee proxy server. This is something implemented in order to test the handler_proxy module when it was incorporated to Cherokee’s code base.</p></div> <div class="paragraph"><p>The idea is pretty simple, and the process straightforward. We tell the QA bench to run through a proxy located in localhost:2222, for instance. We also tell it to wait until we hit enter (-d1) to start executing the lot:</p></div> <div class="listingblock"> <div class="content"> <pre><tt> cd qa ./run-tests.py -Plocalhost:2222 -d1</tt></pre> </div></div> <div class="paragraph"><p>As you’ll see, it will generate a configuration file for us to launch the proxy server:</p></div> <div class="listingblock"> <div class="content"> <pre><tt> Server PID: 29909 Path: ../cherokee/cherokee-worker Mods: ../cherokee/.libs/ Deps: ../cherokee/ Panic: ../cherokee/cherokee-panic Proxy conf: /tmp/tmprV6k4Hcherokee_proxy_cfg</tt></pre> </div></div> <div class="paragraph"><p>At this point, we only have to open a new terminal, launch the Cherokee proxy server and hit enter to unlock the tester side of the QA bench:</p></div> <div class="listingblock"> <div class="content"> <pre><tt> cherokee -C /tmp/tmprV6k4Hcherokee_proxy_cfg</tt></pre> </div></div> <div class="paragraph"><p>Almost every single QA test can be run through the proxy server. There are a few exceptions though. Tests involving the X-Real-IP header will be skipped, for example. It is not a big deal anyway, those are around 5 o 6 test out of almost 250.</p></div> </div> <div id="footer"> <div id="footer-text"> </div> </div> </body> </html>