Rigor Talks – PHP – #7 – Test Class (Spanish)

Hola Amigos del Rigor! Vamos a arrancar un serie de 4 videos sobre patrones de “Unit Testing”, especialmente, para código acoplado. Aquí os dejo el primero.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

  • ¡Wow! Una técnica súper, súper buena, muy útil. Se me están ocurriendo unos cuantos sitios donde usarlo en el proyecto en el que trabajo.

    Tenía un par de comentarios, a ver qué piensas de ellos:

    1. Entiendo que la técnica consiste en crear una nueva clase que herede de la que queremos testear. En el ejemplo que pones, que sólo habría que sobreescribir un método, la nueva clase es pequeña. Quizá se podría crear un stub del método protegido (bueno, ahora no estoy seguro de que PHPUnit permita hacer eso, permíteme que hable solo de la técnica) y de esta forma evitar tener que crear una nueva clase. ¿Qué opinas sobre eso? Entiendo que hay casos y casos, pero ¿crees que habría ocasiones en las que bastaría con mockear el método extraído?

    2. En el vídeo #5, en el named constructor, cambiaste el new Temperature por new static. No sabía que podía hacerse eso, me pareción interesante. Pero a la vez no me pareció muy buena idea, no me convenció. Veía más claro tener el nombre de la clase junto al new, el código lo leía mejor. Pero en este vídeo, la técnica de Test Class no funcionaría si en el named constructor tenemos new Temperature. En ese caso estaríamos creando siempre una instancia de Temperature, por mucho que estuviéramos llamando a TemperatureTestClass::take, por lo que el método getThreshold no estaría sobreescrito, y los tests intentarían leer el umbral de la base de datos. Así que en este vídeo he visto la utilidad de new static (aparte de aprender una nueva técnica para los tests claro).

    Gracias Carlos por estos pequeños vídeos de donde aprender tantas cosas.

    • cbuenosvinos

      Hola Rubén. Me alegro que te guste. Respondo a tus puntos.

      1. Espérate a la semana que viene y verás dos trucos más para no tener que crear la clase nueva ;). Self-shunt for the rescue!

      2. Con el nombre de la clase explícito se puede leer mejor, pero todo es acostumbrarse. Es la primera vez que lo ves. Luego, cuando haces refactor y cambias el nombre de la clase, no tienes que cambiarlo en tantos sitios. A parte, hay una pequeña mejora de rendimiento (micro). Si quisieras mantener el new Temperature, tendrías que también sobreescribir el named constructor.

      Me alegro que los videos sean útiles, para eso los hago ;)
      Un abrazo!

      • Sí, bueno, con new static pierdes el nombre de la clase, pero en parte se entiende que estás haciendo new de la clase en la que te encuentras, así que el contexto lo tienes. Supongo que será cuestión de acostumbrarse.

        Por otro lado, es un buen punto lo de tener que hacer menos cambios en los refactors. Y si copias&pegas ese código a otra clase (ok, sé que eso está mal, pero quien no lo ha hecho alguna vez), tampoco lo tendrías que cambiar.