Three obvious things we missed in testing

This summer we released a new version of the weather site Vä (“The Weather Channel” in Swedish), this time built using the Ruby on Rails framework. Although we have a few tests in the test suite for the site it is far from complete. Three of the things that we have fixed since the release are results of phenomenons that shouldn’t come as a surprise. Three things that are not as certain as death and taxes but not far from it:
  1. There are months with 31 days.
  2. We actually have daylight saving time.
  3. It’s cold in the winter.

One: The first phenomenon was discovered in the end of  August when suddenly the forecasts for September 1st shown on the site was dated as October 1st. It took a while before we realized what happened. The code for setting the date looked something like this:

var forecastDay = new Date(2010,7,31);
Tue Aug 31 2010 00:00:00 GMT+0200 (CEST)
Fri Oct 01 2010 00:00:00 GMT+0200 (CEST)

Since August have 31 days but September only 30 the 31st day of September really is October 1st. So when we set the day after setting the month we are suddenly in October. The easy fix? To set the day of month before setting the month. The correct fix? To set year, month, and date in the same method call.

Two: Around the end of October a few days before Europe goes back to normal time we see that a number of forecasts are missing. Since we have had trouble with our data supplier, SMHI – the Swedish national weather service, earlier on they are our prime suspect. But when we look at the data files they supply they look to have all data they should have. There is however one thing that look different. After the following Saturday all forecasts are given another timestamp. The forecasts are now for 1pm instead of 2pm. The Javascript code assumes however that the timestamp will be the same as first day of the ten-day forecast. So during transition between daylight saving time and standard time some forecasts will be missing. I guess the error partly can be blamed on our data supplier since the time zone used should have been documented. But mainly it is our fault since the transition shouldn’t have come as a surprise.

Three: When the Flash rendering of the ten-day forecast suddenly went blank for some places up north last week we had a number of theories on the cause. Once again the weather service was a prime suspect but the data was in order so we began to think that it was something different with the data that the Flash code couldn’t handle. And sure enough, it turns out that the code rendering the curve of temperatures didn’t work when all temperatures in the forthcoming ten days were in the sub-zeros (Celsius degrees that is).

Testing: One thing to learn from these errors is to setup a number of tests for all corner cases you can come up with. All three of these errors can be classified as such. All three are also errors in code that runs on the front-end. There are tools for unit testing Javascript code, e.g. Jasmine, but they are not used as much as unit tests for backend code and we have just recently begun to use such tools on our TV4 Play project. There is work on unit testing in Actionscript as well (such as AsUnit), but since the code in question was developed by a third-party we should start by having them better document the work they do. And make it possible for us to test.

Läs om vår kommentarspolicy