Otro de mis pequeños proyectos

Etiqueta: error

Problemas con mocks en PHPUnit

A petición de Mariotux, va este post sobre uno de los problemas que me he encontrado cuando he tenido que usar mocks en PHPUnit. Es uno de los errores ya reportados y se da al intentar comprobar llamadas a un método con distintos parámetros.

Supongamos que tenemos una clase como esta que queremos mockear:

class MyClass {
 public function check($param) {
 // Código
 }
}

En el caso concreto de querer comprobar si se realizan, por ejemplo, dos llamadas a esta función pasando $param = ‘one’ y una llamada con $param = ‘two’, es cuando nos encontremos el problema. Por ejemplo:

$mock = $this->getMock('MyClass');
$first = 'one';
$mock->expect($this->exactly(2))->method('check')->with($first);
$second = 'two';
$mock->expect($this->once())->method('check')->with($second);

Aunque la clase que programemos realice correctamente las llamadas, PHPUnit nos indicará que se esperaban 2 llamadas a check, pero se han realizado 3 y, por lo tanto, no pasará el test.

Esta misma semana comentaba con Carlos Ble y hay posibles soluciones, como es generar una clase intermedia que separe ambas llamadas, siempre teniendo en cuenta que podamos hacer ese código y quizás no sea tan sencillo con código legado o con mucho acoplamiento.

A ver si en los próximos releases de phpunit-mock-objects se soluciona este problema.

Problemas con Internet Explorer y hover (css)

La semana pasada uno de nuestros clientes nos puso un problema sobre la mesa que nos ha traí­do de cabeza unos dí­as. El problema en cuestión era que diversas páginas de su web, que eran pesadas (incluso podemos decir que muy pesadas ya que algunas tení­an 4 megas de HTML, pero otras 8, 13 y hasta 15), tení­an un problema de rendimiento bastante grave.

Poniendo en contexto, una vez cargadas esas páginas, es decir, no teniendo en cuenta el tiempo que necesita el navegador para descargar la página ni el tiempo para renderizarla al completo, con su javascript, cuando navegamos por la página, Internet Explorer (7 y 8, con la 6 no tanto) empieza a cargar la máquina, subiendo el uso de CPU hasta el 100% durante varios segundos y haciendo imposible la navegación, hasta tal punto que no sólo afectaba al scroll sino que incluso cuando desplazamos el cursor por la página el simple hecho de ponernos encima de un enlace, llegaban a pasar segundos hasta que el cursor cambiaba desde la tradicional flecha al cursor:pointer caracterí­stico en cada sistema operativo y navegador.

Por no hablar del tiempo de respuesta ante los scripts o cualquier evento. Inviable.

Detallar todo el proceso que seguimos nos darí­a para varios posts y varias páginas, pero bueno, habiendo descartando completamente que el problema fuese javascript o el framework que se usaba (en este caso jQuery), el problema parecí­a estar en el tamaño de página porque cuando se reducí­a su tamaño los problemas desaparecí­an y también en la hoja de estilos, porque al comentar algunas de las hojas, el efecto se atenuaba e incluso llegaba a desaparecer.

La primera impresión fue que es posible que al ser la página tan grande y tener muchos elementos que flotaban, alternando con elementos de bloque es posible que el navegador necesitase todo ese procesado, pero comprobamos como ese no era el problema (evidentemente, algo de se notó puesto que efectivamente el navegador tení­a que pensar algo menos), pero no era la causa ya que la mejora no era aceptable.

Finalmente, probando más cosas surgió la idea de comentar todos los hover (también se probó con los float y otros atributos) y cuál fue nuestra sorpresa cuando el efecto desapareció. Centramos toda nuestra atención, esto no lo habí­amos visto nunca.

Sólo habí­a una cosa rara, en unas pocas lí­neas (4 ó 6) tení­amos unas propiedades css similares a estas (no es el caso real, pero sí­ similar):

.listados .visual {color:#777;}
.listados .visual:hover {color:#000;}

Para un HTML como este:

Es decir, resumiendo, las propiedades css hacen que los enlaces con class visual se pongan de color negro cuando el ratón se pone por encima.

Esto supone un gran problema para Internet Explorer. Pese a que la propiedad hover está puesta para un enlace, no poner explí­citamente en los estilos que es para un enlace (tag ) provoca que esté constantemente recalculando y «pensando», y aquí­ la raí­z de todo el problema.

Es decir, las lí­neas css deben ser:

.listados .visual {color:#777;}
.listados a.visual:hover {color:#000;}

Lo más correcto serí­a incluir también el a en la primera lí­nea, para tener más coherencia, aunque no es necesario y no cambia la solución del problema.

Pero bueno, la guerra contra el IE ha terminado… y hemos ganado 🙂

Error cachondo en firefox

Esto es lo que me encontré hace unos dí­as al abrir mi Firefox 3.5. Creo que no hay mejor manera de definirlo:

¿Bueno, esto es embarazoso?

¿Bueno, esto es embarazoso?

De verdad, me quedé sin palabras. No se si el traductor se lo pasa bien, o realmente los creadores de Firefox son unos cachondos con los mensajes de error.

Eso sí­, me dije, esta me la guardo para la posteridad xDD

WTF! Google dice que Google puede dañar tu equipo!

Descubro con Lerele cómo Google opina que él mismo es dañino! La siguiente captura no es fake, me la ha pasado directamente Lerele…

Cuidado! Google es peligroso!

Cuidado! Google es peligroso!

Todo parece indicar que ha sido un error de Google ya que no sólo ellos, sino otras muchas páginas han sufrido durante varios minutos esa terrible frase. Al poco tiempo, todo ha vuelto a la normalidad pero bueno, ya tenemos anécdota para la posteridad 🙂

Update: Ya hay explicación oficial, un error humano.