Probar con curl prueba lo que no es
Una petición de contador que llega sin identificador de navegador escribe en dos de los doce sitios que toca normalmente una visita contada. Responde 200. Devuelve una imagen de contador válida. En ningún sitio dice que diez de los doce se saltaron.
Para qué está el filtro y qué te cuesta
Aquí los contadores separan robots de personas, y la separación se hace por el identificador que el cliente da de sí mismo. La lista de marcas es corta y deliberadamente inequívoca, y curl/ está en ella. Un identificador vacío también, con el razonamiento de que una petición sin identificador alguno no es un navegador.
Ambas cosas son correctas. El servicio no se equivoca al tratar un curl pelado como un robot; eso es lo que es. El problema es que quien maneja el curl normalmente no está comprobando si funciona la detección de robots. Está comprobando si funciona el conteo — y ha pedido en silencio el camino del robot.
Lo que obtiene: el total diario sube uno, la columna de bots sube uno, y ya está. Ninguna fila de visitante único, así que nada sobre visitantes. Ninguna entrada en la lista de conectados. Ninguna página, ni país, ni navegador, ni sistema operativo, ni dispositivo, ni hora. Justo las partes que uno querría comprobar son las que no se ejecutaron.
El fallo no tiene síntoma
Esta es la parte en la que conviene detenerse. Una prueba que no mide nada suele avisar: un error, un resultado vacío, un cero donde debería haber un número. Aquí la respuesta es 200. El cuerpo es una imagen de contador de verdad, 3.361 bytes. El número de la imagen incluso subió, porque el total diario es una de las dos cosas que sí pasaron.
Así que la prueba parece aprobada. Todo lo que se deduce de ella — «el camino de conteo funciona», «la columna nueva se está escribiendo», «el cambio no ha roto nada» — es una conclusión sacada de una ejecución que se saltó la mayor parte del código que debía ejercitar.
Pasó mientras se escribía esto
La primera versión de la medición detrás de esta entrada pedía /c/<número>. Esa no es la dirección de una imagen de contador; la real lleva el diseño y una extensión, /c/<número>-<diseño>.png. La petición devolvió 404.
El script informó tres veces: escribe en 0 de 12 sitios. Lo cual es cierto, y es también exactamente lo que parecería un filtro de bots funcionando si entornas los ojos. El 404 estaba en la misma tabla, una fila por encima de los ceros. Quedó sin leer un minuto porque los ceros eran lo interesante y coincidían con lo esperado.
Es el mismo error del que trata esta entrada, un piso más arriba: una medición que dio una respuesta plausible por un motivo que nadie comprobó. Se detectó solo porque el script cuenta filas en doce tablas en vez de fiarse de la petición — una petición que falla y una que se filtra se ven iguales desde fuera.
Qué hacer en su lugar
Enviar un identificador de navegador. Un solo parámetro, -A con un identificador real, y la misma petición escribe en diez de los doce sitios en vez de en dos.
Y contar del otro lado. El código de respuesta dice que la petición llegó; no dice qué hizo. En todo aquello donde lo que importa es el efecto secundario — un contador, una cola, una línea de registro, una fila en algún sitio — la prueba tiene que mirar el efecto. Contar antes y después en cada tabla implicada costó aquí veinte líneas y convirtió un resultado ambiguo en inequívoco dos veces: una por el filtro y otra por el 404.
Dos de los doce sitios siguieron vacíos incluso con identificador de navegador: la columna de bots, correctamente, y la lista de referencias, que no registró la referencia enviada. Esto segundo no se explica aquí porque todavía no se ha perseguido. Se cuenta porque la alternativa sería enseñar una tabla de once filas y decir doce.