Urushiol fixar cache-tester på TV4

 

Vi på TV4 Digitala mediers teknikavdelning presenterar version 1 av Urushiol, ett testramverk för Varnish-Cache skrivet i Ruby.

Urushiol skrevs för att hjälpa till vid migreringen från Apache till Varnish-Cache, som ska stå framför somliga av våra servrar. Vi märkte ganska snabbt att det inte var så enkelt som att “tuta ‘o köra” när vi fick en drös routing-fel i knät. När vi fixade en route pajade nästa. Det fanns ett behov av att på något enkelt sätt unit-testa våra konfigurationsfiler och då enkelt kunna se vad som fungerade och vart någonstans det gick snett.

Namnet Urushiol kommer från det japanska ordet “urushi” som betyder “lack”. I och med att “varnish” också betyder “lack” och att vårt test-ramverk är skrivet i Ruby, som är japanskt, kändes namnet helt rätt. All kredd går till Brian för dopet av Urushiol.

Urushiol terminal screenshot

 

Testramverk hjälper utvecklare se helheten snarare än att snöa in sig på den del av koden man råkar jobba på just då. När man skriver om kod som har beroenden finns alltid en risk att man pajar någonting som beror på den. Att kunna få en helhetsbild av situationen och direkt kunna se vart beroenden gått sönder är därför guld värt i vår bransch.

Urushiol är en produkt i testar-anda och har hittills fyllt sitt syfte med guldstjärna i kanten. Kicka gärna in på Github eller ladda ner Urushiol från RubyGems och testa själv!

 

Three obvious things we missed in testing

This summer we released a new version of the weather site Väderkanalen.se (“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);
undefined
forecastDay
Tue Aug 31 2010 00:00:00 GMT+0200 (CEST)
forecastDay.setMonth(9);
1288476000000
forecastDay.setDate(1);
1285884000000
forecastDay
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.