Etiqueta: error

Problemas con mocks en PHPUnit

2010-11-22 / tatai / Sin comentarios

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)

2010-10-21 / tatai / Sin comentarios

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 🙂

Error cachondo en firefox

2009-08-13 / tatai / Sin comentarios

Â¿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!

2009-01-31 / tatai / Sin comentarios

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!

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.