nov 22 2010

Problemas con mocks en PHPUnit

tatai

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.


oct 21 2010

Problemas con Internet Explorer y hover (css)

tatai

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:

<div class="listados">
<p><a href="#" class="visual">Texto</a></p>
<p><a href="#">Texto</a></p>
<p><a href="#">Texto</a></p>
<p><a href="#" class="visual">Texto</a></p>
</div>

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 <a>) 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 :)


ago 13 2009

Error cachondo en firefox

tatai

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


ene 31 2009

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

tatai

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.