Tester med curl testar fel sak

En räknarförfrågan som kommer utan webbläsaridentitet skriver till två av de tolv ställen som ett räknat besök normalt berör. Den svarar 200. Den returnerar en giltig räknarbild. Ingenting någonstans säger att tio av de tolv hoppades över.

Vad filtret är till för, och vad det kostar

Räknarna här skiljer robotar från människor, och uppdelningen görs utifrån den identitet som klienten själv uppger. Listan med kännetecken är kort och medvetet entydig, och curl/ finns med på den. Det gör också en tom identitet, med resonemanget att en förfrågan helt utan user agent inte är en webbläsare.

Båda delarna är korrekta. Tjänsten gör inte fel när den behandlar ett naket curl som en robot; det är vad det är. Problemet är att den som kör curl oftast inte vill testa om robotdetekteringen fungerar. Det man vill testa är om räkningen fungerar, och i tysthet har man bett om robotvägen.

Det man får: dagens totala antal visningar ökar med ett, botkolumnen ökar med ett, och det är allt. Ingen rad för unika besökare, alltså ingenting om besökare. Ingen post i onlinelistan. Ingen sida, inget land, ingen webbläsare, inget operativsystem, ingen enhet, ingen timme. De delar av systemet som någon faktiskt skulle vilja kontrollera är just de delar som inte kördes.

Felet har inga symtom

Det här är den del som är värd att stanna vid. Ett test som inte mäter något brukar avslöja sig självt: ett fel, ett tomt resultat, en nolla där en siffra borde stå. Här är svaret 200. Innehållet är en riktig räknarbild, hela 3 361 byte. Siffran i bilden gick till och med upp, eftersom det totala antalet visningar är en av de två saker som faktiskt hände.

Så testanropet ser godkänt ut. Allt som bygger på det — ”räknevägen fungerar”, ”den nya kolumnen skrivs”, ”ändringen förstörde ingenting” — är en slutsats dragen från en körning som hoppade över det mesta av koden den skulle ha testat.

Det hände medan det här skrevs

Den första versionen av mätningen bakom det här inlägget begärde /c/<number>. Det är inte adressen till en räknarbild; den riktiga innehåller designen och en filändelse, /c/<number>-<design>.png. Förfrågan returnerade 404.

Skriptet skrev ut, tre gånger: skriver till 0 av 12 ställen. Vilket är sant, och vilket också är exakt hur ett fungerande botfilter skulle se ut vid en snabb blick. 404:an fanns i utdatan, i samma tabell, en rad ovanför nollorna. Den förblev oläst i en minut, eftersom nollorna var det intressanta och stämde med det som förväntades.

Det är samma misstag som det här inlägget handlar om, en nivå upp: en mätning som gav ett rimligt svar av ett skäl som ingen kontrollerade. Det upptäcktes bara för att skriptet räknade rader i tolv tabeller i stället för att lita på förfrågan — en förfrågan som misslyckas och en förfrågan som filtreras ser identiska ut utifrån.

Vad du ska göra i stället

Skicka en webbläsaridentitet. En flagga, -A med en riktig user agent-sträng, så skriver samma förfrågan till tio av de tolv ställena i stället för två.

Och räkna något på andra sidan. Svarskoden säger att förfrågan kom fram; den säger ingenting om vad förfrågan gjorde. För allt där poängen är sidoeffekten — en räknare, en kö, en loggrad, en rad någonstans — måste testanropet titta på sidoeffekten. Antal före och efter i varje berörd tabell krävde här tjugo rader kod och gjorde ett tvetydigt resultat entydigt två gånger: en gång för filtret, en gång för 404:an.

Två av de tolv ställena förblev tomma även med en webbläsaridentitet: botkolumnen, helt korrekt, och listan över hänvisande sidor, som inte registrerade den hänvisning som skickades. Det andra förklaras inte här, eftersom det ännu inte har utretts. Det redovisas eftersom alternativet vore att publicera en tabell med elva rader och kalla den tolv.