Testing If-Modified-Since with lwp-mirror

This week I created a way for me to post small messages, as there is not yet a good decentralized way to make this happen. One part of this research is how can I create, host and share RSS feeds without using to much bandwidth and server time.

One way we can do this, is by using the features of the HTTP protocol. One of those features is the Last-Modified header. This header allows web servers and user agents to see when a resource was last modified. Together with a If-Modified-Since header we can let our software check if it needs to send the whole body or just the a simple 304 header.

However to make sure if this works as advertised, we need a way to simulate this situation. I use lwp-mirror to test this, which is included with the LWP package from Perl. It mirrors a remote resource to a local file.

Let's start the test. First download your resource to a file with the lwp-mirror command.

lwp-mirror <url> <local_file>

Now download the file again and check if it sends a 304 code now. Then do something that changes the resource on the server. In my case this is done by added a new post. Now download the resource again and see if it sends a new version of the file. Once downloaded, you check if you get another 304 code.

Testing for improvement

When I'm programming, I sometimes need to use a problem solving pattern, that Kent Beck called Parallel. The pattern tells us that when your making a change you should also leave the old way of doing things in the program, so you can gradually move to the new solution. This helps in situations, where you can't just flip a switch to migrate.

The problem with this however is, that you do have to migrate all the way to the new solution, because otherwise you will have twice the code and data in various states.

When I'm using Parallel, I like to keep an eye on the progress and I don't like to go back to the old way. To help me with this I created a unit test that monitors the progress that I make, while changing the program and the data.

It would be nice to have a test module that keeps track of this, but at the moment I only have a small test program. It does three things:

1. Read the previous count (of old way occurences)
2. Check if the current count is smaller or equal to the previous count.
3. If true, the test succeeds and then writes the count to a file. If false, the test will fail.

This way the tests will only succceed if I make improvements or if the code stays the same. This way it can only improve the code.

Help prove help you

I use prove from Test::Harness to test the code of my Perl projects. The program prove runs tests files and summarizes the output. If tests fail then it shows the error in its output.

The problem is, my defaults aren't the same as the defaults that prove uses. I keep my main application files in app/lib and a few vendor libraries in vendor. The problem with this is that I have type out the options of prove every time I wanted to test. For the longest time I used a Makefile to solve this problem.

Then I found out about .proverc. If you put this file in your current directory of in your home directory, then prove will use each line as an extra command-line option.

The .proverc in the root dir of my project looks like this:

-Iapp/lib
-Ivendor
-r

It includes two extra directories in the Perl include path; app/lib and vendor. It also find all test files recursively in the t directory, which is also not a default setting of prove.

Perl Testing Book Received

Yesterday I received the Perl Testing Developers Notebook. It only took about six days to get here, but it still is three months ago, since I won. Of course this is no problem and I'm very happy with the new book.

I like to thank Josh, for the contest. Which was actually quite easy :).

I've started reading it and it looks like it contains real nice examples for perl testing. Some stuff that will be really useful, when I'm working on the webshop and the concert website.