Save Time with Super-Quick Local Test Cases
If you’re anything like me, you’ve probably created local test cases before - quick little bits of code to try something out.
Maybe you’re trying to isolate a bug that’s been doing your head in, or perhaps you’re learning a new language and want to try out a new feature?
Whatever the reason, the point of test cases is that they’re quick and often just stay local rather than being uploaded for all to see. Your mileage may vary, but that’s certainly the case for me anyway.
If I’m making a test case, it’s because I want to get in, test my stuff, and get out of there. So the quicker and easier I can make it for myself, the better. I thought I was doing quite well by having a local testing domain in MAMP so I could easily just drop stuff in there and keep my test cases separate from my actual work, but today I hit upon something that takes the idea further and boils the test case creation process down to its essence - writing the code you actually want to test.
The Test Domain
If you work locally and don’t have a dedicated testing domain set up already, this is the first step. It’s as simple as creating a directory and then pointing your domain of choice at said directory, then dropping the files in. If you use some kind of GUI like MAMP Pro to manage your local domains this shouldn’t take more than a minute or so. I use the suffix “.local” for my local domains, so from here on in we’re working on the domain
The second ingredient in our time-saving recipe is the wrapper. Since this is for quick testing, I’ve christened it
quick.php (clever, eh?) but you can call it whatever you want and write it in whatever server-side language you like. Save the wrapper file in the root of your testing domain - for me it’s
What the wrapper does is take care of the stuff that’s common to every test case. For example you’ll need the basic HTML structure so you’re working with valid markup, and you’ll probably have some default styles you want to apply to your test cases, because who wants to look at the browser defaults, right?
My wrapper code is below - you can see that it very simply takes a couple of parameters from the URL and plugs them into a minimal HTML5 structure. One is the (optional) document title, the other is the name of the file that contains the actual test case, minus its file extension (e.g. “test” instead of “test.php”).
<!doctype html> <html lang="en"> <head> <meta charset="utf-8" /> <title><?php echo $_GET['title']; ?></title> <link rel="stylesheet" href="quick.css" /> </head> <body> <?php require_once($_GET['filename'].'.php'); ?> </body> </html>
The security-conscious amongst you will have noticed that we’re taking input from a URL and plugging it directly into the page. This is bad practice and should never be done in production code. I haven’t worried about security here as the test cases aren’t intended for public consumption. If you need to do a public test case for some reason, it’s easy enough to do some basic checks at the top of the wrapper script and save the values into variables for use in the relevant places.
The final stage of preparation is a rewrite rule to make it as simple as possible to access our test cases. I mainly use Apache so I’ll do this via
.htaccess, but you can easily achieve the same thing in nginx, IIS, whatever you choose.
The .htaccess goes in the root of your testing domain. It contains just a single RewriteRule that takes a nice clean URL and passes it to our quick-and-dirty wrapper file for processing. Here’s the contents of mine:
RewriteEngine on Options +FollowSymlinks # quick tests RewriteRule ^quick/(.*?)(/(.*?))?$ quick.php?filename=$1&title=$3 [L,NC]
Don’t be alarmed by the regular expression in there. Regexes are a dev’s best friend, and this one is really quite simple. It takes a URL in the format
test.local/quick/[filename]/[title] and rewrites it into the format
test.local/quick.php?filename=[filename]&title=[title]. If you don’t care to give your test case a title, you can also use
If you don’t want to know the gritty details of the regex, feel free to skip this section - I won’t be upset. But if you're not familiar with regular expressions, I strongly recommend you look into them - they’ll save you a lot of time in the long run! This screencast series over at NetTuts+ explains everything from the ground up, so there's no need to be scared.
So, back to that regex. It looks like a mess of brackets, but if we look under the bonnet you’ll quickly see how it works.
When the regex encounters a URL in the right format, it breaks it down into three parts - the filename, the title including a “/” and just the title. The filename part is simple - just match any string or characters after the first “/”.
The title part has a little more to it - the pattern
(/(.*?)) will first match the second “/” character and any string following it, but then it will match just the string after the second “/”, so we don’t need to worry about removing it from the title later.
The final “?” makes the whole lot optional, so if you choose not to bother with a title the rewrite rule still matches.
Creating a test case
Now we just need to create a test case. This can be anything you want to test, but as an example I’ll be comparing three different line-spacing values for a short paragraph. The markup for my test case looks like this:
<p style="line-height:1em;">Lorem etc…</p> <p style="line-height:1.25em;">Lorem etc…</p> <p style="line-height:1.5em;">Lorem etc…</p>
Notice that we just write the stuff we want to test. No need for the HTML
<head> and all that stuff. Save the file to your testing domain and give it a filename that’s easy to type in a URL. The only restriction is that you have to save it with the right extension for the server-side language you used to write the wrapper. Let’s go with
test.php in this case.
Once you’ve saved your file, open up your browser and go to http://test.local/quick/test/A Quick Test - obviously, substitute the right values for your testing domain, wrapper file and test case file. All being well, you should see your test case displayed nicely, with a proper title and everything.
Now, all that might seem like a lot of effort to save a little time on each test case, but in reality it only took me about ten minutes to set up from scratch, so if you follow this tutorial you can probably do it in about five.
From now on, whenever you want to write a test case you can just save a tiny new file in the root of your testing domain and type the appropriate URL into your browser - no fiddling around finding the HTML structure again or having to set up default styles each time.
Depending on what you do with it, you’ll probably be into time profit after half a dozen test cases, which won’t take very long at all if you’re as compulsive with them as I am!
Photo: Test Tubes by Dan Machold
Posted on Thursday, 15th December 2011.
Sorry, feedback is now closed on this post, but please feel free to get in touch if you would like to talk about it!