Refactorizando el cliente de “Cat API” – Parte 3 –

Esto es una traducción libre de Refactoring the Cat API client – Part III

En la primera y segunda parte hemos estado trabajando en separar las preocupaciones que teníamos al principio combinadas en una sola función.

Los principales “personajes” en el escenario ya han sido identificados: un httpClient y una caché, utilizadas por diferentes implentaciones de CatApi para poder testar y realizar un cliente para The Cat Api

Continúa leyendo “Refactorizando el cliente de “Cat API” – Parte 3 –”

Refactorizando el cliente de “Cat API” – Parte 2

Esto es una traducción libre de Refactoring the Cat API client – Part II

El mundo un sitio seguro

Cuando estas ejecutando test unitarios, no quieres que el resto del mundo este involucrado en tus tests. Ejecutar consultas en bases de datos reales, hacer peticiones HTPP, escribir en ficheros, nada de esto es deseable: harán que tus tests sean lentos e impredecibles. Si el servidor en el que estas haciendo tu petición está caído, o responde de manera inesperada tus test unitarios fallarán por razones equivocadas. Un test unitario solo debería fallar si tu código no hace lo que se supone que debería hacer.

Como hemos visto en el post anterior de la serie, tanto la clase CachedCatApi como RealCatApi de alguna manera dependen del mundo. La primera escribe ficheros en el sistema de ficheros, la segunda hace peticiones HTTP. Además, la creación de fichero y las peticiones HTTP son cosas de bastante bajo nivel, para lo cual las clases no utilizan las mejores herramientas disponibles. De la misma manera, un montón de casos límite no están siendo tenidos en cuenta.

Continúa leyendo “Refactorizando el cliente de “Cat API” – Parte 2″

Buenas prácticas de desarrollo en Etsy Parte 3

Esta es la tercera parte de la traducción del manual de buenas prácticas de Testing en Etsy donde se aborda el tema del Legacy Code.

Legacy code

La mayoría del código fuente que ha sobrevivido normalmente no fué escrito con un diseño limpio o pensando en la usabilidad/reutilización. Puede tener estado global, o no tener ninguna abstracción ( de modo que, por ejemplo, todas las operaciones de base están en una clase o en un método aislado que no está relacionado con la base de datos).

Vamos a tener que utilizar la imaginación cuando nos encontramos con código como este. Al final, nuestro trabajo está por hacer, tenemos que diseñar el código de acuerdo a unas normas, independientemente de como interactue ahora.

Continúa leyendo “Buenas prácticas de desarrollo en Etsy Parte 3”

Buenas prácticas de desarrollo en Etsy Parte 2

Esta es la segunda parte de la traducción del manual de buenas prácticas de Testing en Etsy

Testeando las partes juntas

El código ha sido escrito para el cliente y el servidor, pero solo ha sido testeado de manera separada. Nosotros queremos testar que el sistema actual funciona, por ejemplo que nosotros podemos enviar un trabajo real desde un JobClient a un JobServer real.

Una aproximación común es empezar a testear cada interacción entre cualquiera de las 2 partes del sistema (a veces son llamados ‘test de integración’).

¿Qué estamos testeando exactamente?

Preguntate a ti mismo que ocurre entre un cliente y un servidor que no pueden ser testeados el uno o el otro individualmente. Esto son las cosas de las que no debemos preocuparnos a este nivel, porque setear componentes de la vida real para testearlos al mismo tiempo es más difícil que testearlos uno por uno por separado. Así que contaremos con ese esfuerzo.

Continúa leyendo “Buenas prácticas de desarrollo en Etsy Parte 2”

Refactorizando legacy code en PHP Parte 9 – Los últimos toques

Ya casi estamos acabando con la refactorización, parece mentira cuando empezamos con un solo archivo PHP, ahora tenemos clases, interfaces e incluso inversión de dependencias. Somos capaces de modificar algo sin miedo porque tenemos tests que nos indican si estamos cometiendo errores. Además podemos ampliar la funcionalidad de nuestra aplicación de una manera más o menos sencilla.

En este tutorial vamos a atacar a la “clase” GameRunner. Bueno a los métodos del archivo GameRunner para convertirlos en una clase para más adelante terminar de refactorizar los métodos que nos quedan de la clase Game.

Llegando a ser orientado a objetos

A pesar de que tenemos la mayor parte de nuestro código orientado a objetos, algunas funciones están solas en un archivo. Así que el objetivo de este post es convertir esos procedimientos en algo más orientado a objetos.

Continúa leyendo “Refactorizando legacy code en PHP Parte 9 – Los últimos toques”

Refactorizando legacy code en PHP Parte 8 – Inyección de dependencias

Volvemos otra vez a la carga refactorizando nuestra aplicación php legacy. Esta es la serie de posts más larga que he hecho hasta el momento, pero creo que el tema lo merece.

Esta entrega empezaremos ha plantear la arquitectura de la aplicación, o al menos una separación lógica de clases que irá evolucionando. Nuestra arquitectura debe centrarse en la lógica de negocio. Alrededor de esta tendremos varios módulos “auxiliares” que tienen diversos fines.

Por ejemplo conectar al usuario con la aplicación, en nuestro caso será la linea de comandos. Por otro lado tenemos la persistencia, que en nuestro caso no nos afecta ya que no utilizamos nada de este tipo. También tenemos las factorías y constructores y por ultimo están las clases que representan la entrada al sistema. En nuestra aplicación de Trivial podría considerarse la clase GameRunner de este tipo.

Continúa leyendo “Refactorizando legacy code en PHP Parte 8 – Inyección de dependencias”

Refactorizando legacy code en PHP Parte 7 – Capa de presentación

La capa de presentación

Ya llevamos 7 entregas de como refactorizar una aplicación PHP legacy. Ahora llega el momento de empezar a separar responsabilidades, de ir creando distintas clases y sobre todo de ir mejorando nuestra aplicación legacy en PHP.
Hemos visto a lo largo de los posts que la capa de presentación juega un papel fundamental en nuestro juego de Trivial. Vamos a tratar de identificar todos los sitios donde se haga “presentación” y trataremos de empujar esa “reponsabilidad de representar la salida de la aplicación” a un solo lugar. Para ello nos basaremos en los principios SOLID.

Fundamentos SOLID

Cuando comenzamos una refactorización y empezamos a cambiar código debemos guiarnos por unos principios. Estos principios nos ayudarán a ir tomando decisiones en cada paso de la refactorización. Si hablamos de programación orientada a objetos, los principios que debemos tener en mente son entre otros SOLID. Según la Wikipedia SOLID es un acrónimo mnemotécnico introducido por Robert C. Martin “Uncle Bob” que representa cinco principios básicos de la programación orientada a objetos y el diseño. Cuando se aplican estos principios en conjunto es más probable que un desarrollador cree un sistema que sea fácil de mantener y ampliar en el tiempo.

Continúa leyendo “Refactorizando legacy code en PHP Parte 7 – Capa de presentación”

Refactorizando legacy code en PHP Parte 6 – Métodos complejos

Llevamos ya un tiempo hablando de como refactorizar una aplicación legacy en PHP. Desde que empezamos hemos ido aprendiendo poco a poco a ir reescribiendo código sin perder la funcionalidad de la aplicación. Llegados a este punto, nuestra aplicación legacy ya tiene algunos tests unitarios, utilizamos mocks en algunas partes y lo más importante: Estamos aprendiendo a conocer todo el sistema, hemos leído el código unas cuantas veces y ahora sí podemos atacar a los métodos más complejos.
En mi cuenta de github está todo el proceso que hemos llevado a cabo, además mediante los tags podemos ir viendo como hemos ido evolucionando esta aplicación legacy en PHP para ir convirtiéndola en una aplicación PHP con tests, fácil de entender y con funciones pequeñas.

Entendiendo el método roll()

Cuando leemos el método roll nos damos cuenta de que no devuelve nada por lo que puede que este método sea algo difícil de probar. Así que lo mejor que podemos ir haciendo son pequeñas refactorizaciones automáticas con nuestro IDE y algún “rename” de variables que veamos clarísimo. Si vemos que la refactorización se pone un poco cuesta arriba siempre podemos utilizar el test master comparando ficheros de texto.

Continúa leyendo “Refactorizando legacy code en PHP Parte 6 – Métodos complejos”

Refactorizando legacy code en PHP Parte 5 – creando test sencillos

Refactoring de una aplicación PHP Legacy. Después del intenso post sobre como empezar con loo test unitarios en un refactoring en este vamos a trabajar con la clase Game.php, empezaremos a crear pequeños test de funcionalidades para ir refactorizando. Recordemos que la idea es empezar a refactorizar desde verde para intentar no introducir errores en nuestro refactor.

Creando un “Game”

Lo primero que necesitamos para poder empezar a testear es una instancia de Game, para ello lo primero que haremos sera crearnos nuestra clase específica para test (GameTest) y crear un pequeño test para crear una nueva partida de Trivial.

class GameTest extends PHPUnit_Framework_TestCase
{
    public function testCreateAGameOk()
    {
        $game = new Game();
        $this->assertInstanceOf('Game', $game);
    }
}

Parece sorprendente pero sin mayor problema hemos podido crear una instancia de Game fácilmente y nada se rompe.

Continúa leyendo “Refactorizando legacy code en PHP Parte 5 – creando test sencillos”

Refactorizando legacy code en PHP Parte 4 – como empezar con test unitarios en un refactoring

Continuamos con la serie refactoring PHP legacy code. en el post de hoy empezaremos a hacer test unitarios que serán la base de todos los cambios y refactorizaciones futuras. Extraeremos funcionalidades, pequeñas piezas de código que podremos probar con test unitarios.Aunque parezca que solo son unos simples test, no debemos olvidar que estamos trabajando con código “feo”, sin coding estándar. Como siempre iremos dando pequeños pasos para tropezar.

Test unitarios con PHPUnit

Ya hemos hablado en el blog de test unitarios puedes encontrarlo aquí así que no vamos a dar una introducción a los tests unitarios. Además como ya tenemos composer con phpunit instalado solo tenemos que empezar.

Los test unitarios deben ser independientes

Buscando funciones aisladas

Si el código lo permite (como este caso) es recomendable empezar a escribir test de código que podamos probar. Esto nos será útil para comprender la lógica de funciones pequeñas y para ir cubriendo poco a poco el código a testear.

Analizando nuestros archivos, podemos descartar de momento el método run de GameRunner.php porque no tiene ninguna lógica y aunque podemos probarlo no tiene sentido gastar demasiado tiempo en el todavía. Vamos a por un trabajo más fácil para coger un poco de práctica antes. ¿Recordáis el método isCorrectAnswer() que refactorizamos en el anterior post? Vamos a por él.

Lo primero es centrarnos solo en esta función, por lo que de momento vamos a marcar como skipped el test de GameRunnerTest.php y vamos a crear un test específico para testear la función is isCorrectAnswer, pero tenemos un problema la funcion rand() necesitamos hacer algo para controlarla 😉 Así que lo primero será ir a la documentación y hacer una pequeña prueba ¿que pasa si min y max son iguales?

    function testCanFindCorrectAnswer()
    {
        for ($i = 0; $i < 10; $i++) {
            var_dump(rand($i,$i));
        }
    }

¡Mola! Ya tenemos una manera de forzar números aleatorios como nosotros queramos.

Continúa leyendo “Refactorizando legacy code en PHP Parte 4 – como empezar con test unitarios en un refactoring”