Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: TDD

Seleccionando: un día de convivencia con un candidato con kata incluida

Kata en Frogtek

Si nos sigues un poquito seguro que te habrás enterado, buscamos candidatos, ingenieros de software. Detrás de un producto como Tiendatek hay muchas personas trabajando, un equipo que fluctúa y se adapta a las nuevas necesidades, algunos se han ido, otros hemos llegado, incluso algunos se van, aprenden y mejoran buscando nuevas aventuras, y vuelven con fuerzas renovadas. Nos sentimos orgullosos del equipo que formamos, y una parte importante para construir el equipo es el proceso de selección.

Si las personas sólo fuéramos recursos, números o conocimientos, la selección de personal sería muy fácil, seguramente sólo se necesitara una prueba que garantizara que en el CV no se ha mentido. Pero afortunadamente para todos, menos para RRHH, supongo, somos mucho más que números y conocimientos. Somos unos cacharros normalmente con brazos y piernas que tienen sentimientos, que tienen aficiones y afinidades. Y es que cinco personas bien avenidas garantizan mejor trabajo y durabilidad que cinco personas malavenidas.

Por eso nos gusta ofrecer a los candidatos que entrevistamos, y vemos que pueden encajar en el puesto, un día de convivencia en la oficina de Frogtek. Es un día especial. Ahora ya he vivido esa experiencia desde los dos bandos, y desde ambos dos se ve muy enriquecedora. Desde uno de los lados se ve con bastantes nervios e inquietud; acabas con la cabeza llena de demasiada información y, en mi caso, vuelves a casa con un buen dolor de cabeza. Desde el otro lado lo esperas con impaciencia, intentas enseñar y hacer que la otra persona se sienta cómoda, y al final siempre aprendes algo nuevo de la persona que ha venido.
Seguir leyendo

Robolectric: TDD en Android

Llevábamos ya desde nuestros inicios buscando herramientas que nos permitieran practicar TDD para desarrollar las clases de nuestro proyectos en Android. El problema era que las Activity (clase fundamental de las aplicaciones Android) solo podían ser testeadas a través del propio entorno Android, nunca como clase independiente. Por lo tanto, los únicos tests que habíamos realizado sobre esas clases eran tests de integración, que podían tardar del orden de 4 minutos en ejecutarse por completo, lo que nos imposibilitaba el realizar un diseño guiado por tests.

Robolectric (http://pivotal.github.com/robolectric) es una herramienta que nos va a permitir lanzar tests unitarios en Android.

Su uso nos aporta varias ventajas:

  • Ejecuta tests en Android que duran segundos y no minutos, como en el caso de un Android jUnit test.
  • Su velocidad nos permite practicar TDD al crear clases en Android.
  • Podemos usar Mockito o PowerMock en conjunción con los tests de Robolectric.
  • Nos permite utilizar clases de librerías Android, como JSONObjects o JSONArrays, que en otros entornos no podríamos usar.

Como algunas clases de Android no tienen métodos para acceder al estado o las variables que contienen, la gente de Robolectric se ha sacado de la manga los Shadows (ShadowImageView, ShadowRelativeLayout, ShadowActivity, etc.), los cuales nos van a permitir realizar pruebas como esta:

@Test
public void testImagenEsCorrecta() throws Exception {
    ImageView imagenBanner = (ImageView) activity.findViewById(R.id.banner);
    ShadowImageView shadowBanner = Robolectric.shadowOf(imagenBanner);
    assertThat(shadowBanner.resourceId, equalTo(R.drawable.img_banner_grande));
}

Cómo configurar Robolectric para Eclipse:

Estos son los pasos básicos para configurar Robolectric en Eclipse. Recomiendo seguir el quick-start de la web oficial para más detalles:

  1. Crear una nueva carpeta en la raíz de nuestro proyecto que vamos a testear, llamada test.
  2. Crear un nuevo proyecto (u obtenerlo del SVN) llamada MyProjectTest.
  3. Queremos meter el código dentro de la carpeta test antes creada, así que en MyProjectTest haremos clic en propiedades y en Build Path/Source/Link Source seleccionaremos la carpeta test.
  4. Añadir al proyecto el .jar de Android.
  5. Añadir al proyecto el .jar de Robolectric (¡con dependencias!).
  6. Añadir una nueva run configuration en Run/Run configurations, de forma que elijamos Eclipse JUnit launcher y en la pestaña Arguments seleccionaremos Other/Workspace y elegiremos la carpeta raíz del proyecto que queremos testear.

Ejemplo de uso para testear una Activity:

@RunWith(RobolectricTestRunner.class)
public class MyActivityTest {
    private Activity activity;
    private Button pressMeButton;
    private TextView results;

    @Before
    public void setUp() throws Exception {
        activity = new MyActivity();
        activity.onCreate(null);
        pressMeButton = (Button) activity.findViewById(R.id.press_me_button);
        results = (TextView) activity.findViewById(R.id.results_text_view);
    }

    @Test
    public void shouldUpdateResultsWhenButtonIsClicked() throws Exception {
        pressMeButton.performClick();
        String resultsText = results.getText().toString();
        assertEquals("Testing Android Rocks!", resultsText);
    }
}

De momento, Robolectric es un proyecto joven (surgió en noviembre de 2010). Esperamos que esta herramienta mantenga una cierta continuidad, para que podamos obtener el máximo rendimiento a las prestaciones que nos ofrece.

Por ahora estamos experimentando las posibilidades que nos otorga, todavía nos queda por descubrir como crear nuestros propios objetos Cursor dentro de este entorno. Seguiremos informando…

Primer Walqa Coding Dojo

Así es, el viernes pasado, día 21 de enero, se celebró el primer coding dojo realizado en el Parque Tecnológico Walqa, dirigido por Carlos Ble.

Un dojo (道場, literalmente “el lugar de la senda”) es un sitio donde poder practicar y entrenar una disciplina concreta. Simplemente son centros donde se pueden reunir personas con ganas de aprender. Como en todos sitios, es normal que haya gente con más conocimientos que otros, pero esto es precisamente lo que se busca: que el conocimiento puede transmitirse entre los asistentes.

En nuestro caso, las características de nuestro dojo eran las siguientes:

  • Se va a diseñar y programar un problema (o kata) llamado FluentAPI.
  • Debe realizarse por parejas (pair programming).
  • Debe utilizarse TDD.
  • Se realizará en periodos de tiempo determinados, tras lo cuales deberemos cambiar de pareja.
  • No se indicará cuánto tiempo dura cada periodo (así tampoco hay ansias por terminar)

Al evento asistieron más de 30 personas de distintos perfiles y distintas procedencias (Indra, Tafyesa, Universidad de San Jorge, Telefónica I+D,…)

El problema o kata elegido para la ocasión fue el siguiente:

Queremos conseguir una API para acceder a una lista de objetos que sea fácil de leer al ojo humano, al estilo de:

  1. select(“name”).from(users)
  2. select(“name”).from(users).where(“age”).greater_than(18)
  3. select(“name”).from(users).where(“surname”).contains(“rodriguez”)
  4. select(“name”).from(users).where(“age”).greater_than(18).and(“location”).is(“san francisco”)

Y a ello nos pusimos. En el primer periodo parecía que la cosa no terminaba de arrancar, ya que el problema era difícil de abordar en un principio. Por las mesas se veían lenguajes tan dispares como Java, Ruby, PHP, .Net o Python.

Al sonar la alarma y acabar el primer pomodoro, nos dirigimos a una sala habilitada por Walqa con aperitivos y bebidas, que de seguro nos sirvió para descansar y consultar algunas dudas (como el uso de import static en Java, que resultó fundamental para la resolución del problema)

Acabadas las sesiones de programación, nuestro sensei Carlos Ble se puso a los mandos del portátil y se dispuso a ejecutar una forma de resolver el problema en Python. Mientras, los asistentes observaban el proyector con lo que iba realizando, en medio de un silencio solemne.

Tras lo cual, Carlos dejó continuar la resolución a dos de los presentes: Dani y Rubén, que se enfrentaron a una modificación del problema ante todos los asistentes.

Y hasta aquí dio tiempo. Los participantes salimos muy contentos con la experiencia y alguien llegó a decir que había sido el coding dojo con más afluencia de los realizados en España. ¿Será verdad? 🙂

P.D: nuestra intención es que este sea el primero de una larga lista de eventos.

P.P.D: tenemos nuestro propio hashtag: #codingdojohuesca

Curso de TDD en Zaragoza con Carlos Ble

Los días 18 y 19 de enero tuvimos la oportunidad de asistir a un curso de TDD impartido por Carlos Ble. Durante dos días, estuvimos aprendiendo la base del Test Driven Development y programando en parejas con diferentes personas, de diferentes empresas y con diferentes backgrounds de desarrollo. Vamos, pasándonoslo bien :).

El primer día descubrimos los principios SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion), que deben cumplir los métodos y clases que vayamos a implementar, que viene a ser lo siguiente:

  • Single Responsibility -> Un objeto debe tener una sola responsabilidad.
  • Open/Close Principe -> Las entidades de software deben estar abiertas a ser extendidas, pero cerradas a las modificaciones.
  • Liskov substitution-> Un objeto en un proceso puede ser sustituido por otro sin que se altere la funcionalidad de dicho proceso.
  • Interface Segregation Principle-> Los clientes no debería ser forzados a depender de interfaces que ellos no usan.
  • Dependency Inversion Principle-> Módulos de un nivel alto no deberían depender de módulos de bajo nivel.

TDD realmente no es una herramienta “para testear”, sino para diseñar tu API, para pensar y montar la arquitectura de la aplicación. Si simplificamos los pasos a seguir para hacer TDD, serían los siguientes:

  • Crear una hoja de ruta con las especificaciones que queremos para una funcionalidad concreta
  • En esa hoja de ruta, apuntar todos los posibles casos que se nos ocurran.
  • Para cada caso de uso apuntado en tu hoja de ruta, montar un test pensando en cómo debería usarse dicha funcionalidad (al principio, es posible que ni compile el código, ya que todavía no hemos implementado nada de la API (¡luz roja!).
  • Para cada test, hacer la mínima funcionalidad, de forma que el test pase (¡luz verde!).
  • Una vez que el test pase, refactorizar.

Sin duda una de las fases más importantes en el TDD: La refactorización nos permite darnos cuenta de cosas como:

  • Nomenclatura de nombres. ¿Estamos siendo claros? ¿Queremos expresar bien lo que hace tal método? ¿”hacerCosas” es buen nombre para un método? 😉
  • Extracción de métodos/clases. ¿Realmente este método debería estar en esta clase? ¿Qué responsabilidad tiene?
  • Arquitectura. ¿Usamos Interfaces para montarnos una buena arquitectura? ¿Cómo se van a comunicar los objetos entre sí? ¿Inyección de Dependencias? Particularmente esta es la parte que más me interesó, ya que aunque todos conocemos la herencia y tal, quizás no la usemos tanto como deberíamos.

El segundo día fue realmente revelador: aprendimos a usar mocks, particularmente el framework Mockito para Java. Cómo simular accesos a base de datos o conexiones a un servidor. El tema de los mock merece un post aparte, sin duda.

Un curso muy recomendable para aquellos que quieren meterse en el mundo del TDD y la creación de buen código. Además de pasártelo bien, programando con gente desconocida (creo que es lo que más me gusta), aprendes un montón.