Automatizando para pensar en el problema y no en recordar comandos cuando programamos en PHP

¿Cuantas veces te ha pasado que hecho una pull request y aparecen 300 cambios porque el code style es distinto? ¿O qué nos ha faltado añadir un tipado en los parámetros de una función? ¿Cómo saber si tenemos alguna librería vulnerable? A mí estas cosas me han ocurrido más de una vez por eso intento tener todas estos temas automatizados, ya sea por medio de librerías, teniendo plantillas o atajos.

La idea que hay detrás de automatizar es tener un feedback loop lo más rápido posible y poder darnos cuenta de esos errores/mejoras cuanto antes. Quien me conoce sabe que más de una vez he contado la metáfora de la mochila: mientras estamos desarrollando llevamos una mochila con varios temas: la carga cognitiva intríniseca que hay en programar, ver ese trozo de código que habría que modificar, no perder el norte porque la idea es añadir X feature, los tests, el code style, si hay que añadir un caso nuevo a los tests, si los test son legibles, si el código lo entenderé dentro de 2 semanas, como afecta ese cambio al resto de la aplicación… tenemos que mantener la mochila lo más «vacía» posible para de verdad centrarnos en lo importante.

Photo by Tim Samuel on Pexels.com

Por todo eso, en este post vamos a contar una serie de librerías, plantillas,etch para automatizar todo lo posible un pryecto en PHP y hacer que podamos dedicarle más tiempo a pensar y menos a recordar cómo era ese comando que tienes que lanzar o si la llave iba en la misma linea o en la siguiente. Vamos a hablar solo de librerías y de nuestro entorno local, pero debemos de tener en cuenta que todo lo que vamos a contar podríamos llevarlo a nuestro pipeline de Integración Continua con tan solo rellenar un YML

Continúa leyendo «Automatizando para pensar en el problema y no en recordar comandos cuando programamos en PHP»
Anuncio publicitario

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»

Mejorando con Mockery – Separando responsabilidades

Hace poco empezamos haciendo nuestra primera kata de código utilizando phpunit. En una primera iteración conseguimos una calculadora totalmente funcional. El código de la kata está en github (http://github.com/jeslopcru/php-coding-dojo).
Esta vez vamos a dar un pequeño empujón a la kata, emepzando a utilizar Mockery y sobre todo vamos a seguir aprendiendo buenas prácticas de desarrollo. Para hacer más intenresante la kata podemos activar phpcs o php-cs-fixer para que antes de hacer un commit analicemos el proyecto para hacer que nuestro código se adapte a un estandar. Yo como guía para instalarlo he utilizado esta referencia (http://sergigp.com/phpstorm-integrando-herramientas-de-calidad-de-codigo)

¿Donde lo dejamos?

Teníamos una calculadora funcional, que era capaz de sumar y restar, pero quizás ese switch es algo “feo”. Para quien no lo recuerde este esta es la función que estamos comentando:

    protected function calculate($num, $symbol)
    {
        if (!is_numeric($num)) {
            throw new InvalidArgumentException();
        }

        switch ($symbol) {
            case '+':
                $this->result += $num;
                break;

            case '-':
                $this->result -= $num;
                break;
        }
    }

Añadir más funciones a la calculadora haría aumentar el switch y eso creo que no es una buena solución.

Casi cada vez que utilizamos un switch podemos mejorarlo utilizando polimorfismo. Es cierto que esta regla de cambiar switch por polimorfismo no puede usarse siempre, pero sería bueno tenerla siempre en mente.

Continúa leyendo «Mejorando con Mockery – Separando responsabilidades»

Empezando una kata de código en PHP con PHPUnit

Hace ya un tiempo asistí a una kata TDD en PHPMad, la verdad es que me gustó y pude aprender bastante.

Para entendernos una kata (aplicado a la programación), se traduce en pequeños ejercicios, de menos de 1 hora de duración, que nos ayudan a aprender y mejorar.

Con las katas aparte de aprender podemos mejorar nuestras habilidades y/o nuestros hábitos a la hora de programar. También podemos utilizar atajos de teclado y coger el hábito de «pensar antes de picar». Así que hoy vamos a hacer una pequeña kata.

El problema que he elegido es una calculadora, que aunque sea un ejemplo muy visto, nos irá ilustrando como ir afrontando el reto. El ejemplo está sacado del libro diseño ágil con TDD.

Como base vamos a partir del proyecto https://github.com/matthiasnoback/php-coding-dojo donde tenemos todo lo necesario para hacer funcionar PHPStorm y PHPUnit en conjunto. Si queréis ir echando un vistazo, mis soluciones las iré colgando en mi cuenta de github: https://github.com/jeslopcru/php-coding-dojo

El problema de la calculadora

#Calculator:

Quiero lanzar al mercado un software educativo para enseñar matemáticas a niños. Necesito que puedan jugar o practicar a través de una página web pero también a través del teléfono móvil y quizás más adelante también en la consola Xbox. El juego servirá para que los niños practiquen diferentes temas dentro de las matemáticas y el sistema debe recordar a cada niño, que tendrá unnombre de usuario y una clave de acceso.
El sistema registrará todos los ejercicios que han sido completados y la puntuación obtenida para permitirles subir de nivel si progresan. Existirá unusuario tutor que se registra a la vez que el niño y que tiene la posibilidad de acceder al sistema y ver estadísticas de juego del niño. El tema más importante ahora mismo es la aritmética básica con números enteros. Es el primero que necesito tener listo para ofrecer a los profesores de enseñanza primaria un refuerzo para sus alumnos en el próximo comienzo de curso. El módulo de aritmética base incluye las cuatro operaciones básicas (sumar,restar, multiplicar y dividir) con números enteros. Los alumnos no solo tendrán que resolver los cálculos más elementales sino también resolver expresiones con paréntesis y/o con varias operaciones encadenadas. Así aprenderán la precedencia de los operadores y el trabajo con paréntesis: las propiedades distributiva,asociativa y conmutativa. Los ejercicios estarán creados por el usuario profesor que introducirá las expresiones matemáticas enel sistema para que su resultado sea calculado automáticamente y almacenado. El profesor decide en qué nivel va cada expresiónmatemática. En otros ejercicios se le pedirá al niño que se invente las expresiones matemáticas y les ponga un resultado. El programa dispondrá de una calculadora que sólo será accesible para los profesores y los jugadores de niveles avanzados. La calculadora evaluará y resolverá las mismas expresiones del sistema de juego.
Cuando el jugador consigue un cierto número de puntos puede pasar de nivel, en cuyo caso un email es enviado al tutor para que sea informado de los logros del tutelado. El número mínimo de puntos para pasar de nivel debe ser configurable.

Nuestro primer Test

Lo primero será crear una carpeta para el proyecto llamada CalculatorProject y dentro una carpeta Tests que albergará nuestro primer test.
Como estamos haciendo TDD, debemos tener en mente siempre el ciclo de test driven development Test – Code – Refactor Así crearemos una clase llamada CalculatoerTest con nuestro primer test para la calculadora

<?php

namespace CalculatorProject\Tests;

use CalculatorProject\Calculator;

class CalculatorTest extends \PHPUnit_Framework_TestCase
{

    public function testInstance()
    {
        new Calculator();
    }
}

Continúa leyendo «Empezando una kata de código en PHP con PHPUnit»

patrones test utilizando PHPUnit

Hace unos días vimos algunos patrones para mejorar los tests con PHPUnit, mejorando los assert y/o fixtures. En esta ocasión traemos una serie de patrones para mejorar nuestros tests en PHP.

Veremos una serie de técnicas sobre como afrontar los tests, haremos ejemplos, si bien es cierto que estos ejemplos serán en PHP, la teoría detrás de estos tests puede aplicarse a Java (JUnit), .NET, Python,…

Parametrized test

De vez en cuando, nos encontramos con que estamos escribiendo pruebas casi idénticas, que solo difieren en unos pocos valores, pero la lógica es esencialmente la misma. En estas situaciones es una buena práctica a la hora de hacer test utilizar el patron test parametrizados (parametrized test).

La idea fundamental es de este patrón reside en que solo hay un método de prueba que encapsula la lógica, con la ayuda de PHPUnit lo que hacemos es proporcionar a ese test distintos conjuntos de parámetros.

Continúa leyendo «patrones test utilizando PHPUnit»

PHPUnit y buenas prácticas

Hace ya unas semanas realicé unos post sobre como instalar PHPUnit para empezar con TDD. Hace unos días me llegó desde twitter un post sobre “Ser profesional” (http://plqd.blogspot.com.es/2013/07/ser-profesional.html) En el Pepe Doval cuenta experiencias tratando con personas más o menos profesional. Uno de los puntos clave que cuenta Doval es que el mundo de la programación es muy cambiante, llegan nuevos lenguajes y tecnologías cada día, por ello lo mejor la mejor manera de ser un profesional es aplicar buenas prácticas, desde comentar bien el código, hacer buenos commit, practicar TDD. Por eso llegado a este punto voy a escribir sobre buenas prácticas con PHPUnit.

He de decir que no soy un experto en la materia, esto son solo una serie de recomendaciones extraídas de Internet y que yo intento utilizar en la medida de lo posible, aunque para ser sincero no siempre consigo utilizarlas 😉

Vamos a basarnos en el ejemplo de la cuenta bancaria, es el mismo del post anterior sobre PHPUnit y el ejemplo clave de la documentación de PHPUnit (http://phpunit.de/manual/current/en/index.html)

Sé descriptivo acerca de lo que estás probando

Los test que escribimos deben ser autodescriptivos y con solo un vistazo al código debemos saber que se está probando. Esto puede ser fácil de decir pero bastante difícil de hacer, por ello en PHPUnit están las anotaciones como @Covers.

Continúa leyendo «PHPUnit y buenas prácticas»