Anti-patrones de tests, no cometas los mismos errores que yo

Te llega un email, es otro ticket de ese envío de notificaciones que hiciste hace tiempo, la solución que hiciste tiene otro bug,.. ¿te suena? O abrir un pedazo de código, empezar a leerlo y que te entren sudores fríos porque no entiendes nada o porque lo que vemos allí no quieres tocarlo ni con un palo… y lo peor es que haces un git blame y eres tu mismo el que escribiste eso en un “día de inspiración”. Quizás esos pedazos de código puedan ser un buen ejemplo de anti-patrón. Un anti-patrón es una serie de técnicas que nos conducen a una mala solución para un problema. Lo mejor que puedes hacer con los anti-patrones es conocerlos para así puedas evitarlos en el futuro.

Hoy me gustaría escribirte una pequeña recopilación de anti-patrones de tests. Hace unos años ya escribí sobre “patrones test utilizando PHPUnit” y sobre “patrones de test, mejorando la arquitectura en PHP” así que vamos allá.

Continúa leyendo “Anti-patrones de tests, no cometas los mismos errores que yo”

Crear una API con TDD en GO

En este post vamos a crear una pequeña API en GO aplicando TDD como en toda la serie de post.
Ya tenemos el gusanillo de TDD: hacer un test, el código y refactorizar. Así que vamos a seguir con esa filosofía.

La idea de la API es ir guardando el numero de partidas ganadas por una serie de jugadores y poder consultar el numero de partidas ganadas por jugador.
Básicamente tendremos: Continúa leyendo “Crear una API con TDD en GO”

Poco a poco con Go y TDD: package, funciones, bucles, arrays y cobertura de test

Todo funcionando, $GOPATH, HelloWorld,… ahora vamos a hincar el diente de verdad a Go con TDD.
Crearemos una pequeña calculadora con la que aprenderemos a hacer un package, funciones, tocaremos un poco los arrays y además nos servirá para mejorar nuestras skills de TDD.

Empezando por los test

Para empezar con la calculadora, vamos a crear un package llamado calculator, así que creamos un directorio con ese mismo nombre (calculator) y nuestro primer fichero será calculator_test.go (TDD a tope).

*nota: solo puede existir un package por directorio

El código de ese primer test será algo así:

package calculator

import "testing"

func TestAdder(t *testing.T) {
    sum := Add(2, 2)
    expected := 4

    if sum != expected {
        t.Errorf("expected '%d' but got '%d'", expected, sum)
    }
}

Si nos hemos fijado un poco en el mensaje de error, vemos que ahora utilizamos %d en lugar de %s porque lo que queremos es imprimir por consola un número.

Si ejecutamos go test nos aparecerá que no esta definida la función Add

$ go test
# github.com/jeslopcru/golang-examples/02-calculator
./calculator_test.go:8:9: undefined: Add

Compilation finished with exit code 2

7997258366_7e77afa99d_z
Atardecer – Paula Gonzalez Perez

Continúa leyendo “Poco a poco con Go y TDD: package, funciones, bucles, arrays y cobertura de test”

Ventajas y/o puntos fuertes de la integración continua

Ahora está cada vez más a la orden del día eso de la “integración continua”, “entrega continua”, “inspección continua” y palabros parecidos. Pero cómo explicarle a alguien puramente de negocio qué es eso de la integración/inspección continua y que beneficios conlleva el esfuerzo y la inversión en todo eso. Este artículo es una traducción “libre” de este http://blog.codeship.io/2013/04/11/a-business-case-for-continuous-integration.html

Aunque hablamos de integración continua, este término engloba también el hecho de realizar inspección continua, test unitarios, aseguramiento de la calidad, etc. sobre el producto/proyecto software.

En este artículo se analizan las ventajas de la integración continua de la implementación del software.

Sobre el terreno los beneficios de la integración continua son:

  •  Prevención y reducción de errores de “puesta en producción”.
  •  Generación de análisis y presentación de informes sobre la “salud” del código.
  •  Erradicación de los extensos manuales de instalación.

En términos de negocio, el valor de la integración continua es:

Openxava y los Test JUnit

En anteriores post ya hemos desarrollado un poco con Openxava. Pero el ciclo no esta completo, debemos testear nuestra aplicación y lo mínimo (mínimo, mínimo) debe ser al menos una serie test funcionales (si son automáticos mejor). Así que pare ello utilizaremos JUnit.

JUnit es un conjunto de bibliotecas  que son utilizadas en programación para hacer pruebas unitarias de aplicaciones Java.

OpenXava nos proporciona una clase llamada ModuleTestBase que por medio de HTMLUnit permite automatizar las pruebas como si las estuviésemos haciendo desde el navegador.

Creando una prueba unitaria para Openxava

Vamos a partir de que tenemos un modulo Customer que funciona. Openxava es sencillo y para crear un test solo tenemos que crear una clase llamada CustomerTest dentro del paquete org.openxava.invoicing.test La clase de test debe extender a ModuleTestBase.

Así que allá vamos:

package org.openxava.invoicing.test;
import org.openxava.tests.*;
public class CustomerTest extends ModuleTestBase{
public CustomerTest(String testName) {
 super(testName, 
 "Invoicing", 
 "Customer"); 
 }
}

Esto es solo el principio, ahora tenemos que crear el test propiamente dicho.

Continúa leyendo “Openxava y los Test JUnit”