Como candidatos nos ha tocado hacer multitud de pruebas, y nunca hemos recibido ningún tipo de feedback, así que ahora que nos toca a nosotros, creemos que es un buen momento para tratar a los demás como nos gustaría que nos hubieran tratado.

Lo primero, esto no es un examen: es una opinión. Algunos candidatos entran en controversia con nosotros, y esto es algo bastante desagradable. Por supuesto siempre estamos abiertos a que alguien nos explique algo, y muchas veces hemos aprendido cosas con las pruebas de los candidatos, pero entiende que es muy desagradable cuando un candidato quiere convencerte de algo que no es.

Al final, si crees que estamos equivocados, es posible, simplemente somos programadores como tu, y por supuesto a veces nos equivocamos.

Candidato

Una prueba técnica tiene que estar muy orientada al tipo de candidato que estás buscando. No tiene mucho sentido hacer una prueba de algoritmia y patrones de diseño para un perfil que va a trabajar con wordpress.

En nuestro caso buscamos perfiles con varios años de experiencia, con un conocimiento razonablemente bueno del framework con el que trabajamos, pero que todavía tenga un buen margen de crecimiento junto a nosotros. Es decir buscamos a alguien que pueda ser productivo en un corto plazo, que pueda trabajar la mayor parte del tiempo de forma independiente, pero que el desarrollo profesional y el aprendizaje que puede adquirir con nosotros sea algo importante para él.

Descripción de la prueba

Nuestra prueba es realmente sencilla. No voy a describirla aquí, porque la cambiamos con cada proceso, pero básicamente pedimos que se instale un proyecto con symfony y que se programen un par de acciones, y algún comando. Todo ello sin dar ningún tipo de instrucción acerca de cómo hacerlo. Si acaso se insinúa ligeramente al candidato que sea creativo.

Consejos iniciales

Criterios de evaluación

Como verás en las cosas que evaluamos a continuación. es una prueba tan sencilla en la que buscamos es que seas muy detallista en las pequeñas cosas.

Asignaríamos una puntuación 1-10 para cada uno de los siguientes apartados, de forma que pudiéramos valorar de forma justa y a la vez sencilla para nosotros. Los criterios de evaluación no están en orden de importancia. Tampoco hacemos una media artimetica del resultado, simplemente es una guía para saber cuales son tus puntos fuertes y cuales son tus puntos debiles. El resultado de la prueba técnica, junto con la evaluación personal que hagamos, será lo que nos ayude a decantarnos por uno u otro candidato.

El README.md es una de las partes más importantes de la prueba, ya que te da la oportunidad de explicar y justificar las decisiones que has tomado.

Pon atención a las faltas de ortografía. No pasa nada, el que esté libre de pecado que tire la primera piedra, pero mi recomendación es que si sueles cometer faltas de ortografía, lo pases por un corrector antes de enviarlo.

Versiones

Valoramos positivamente que utilices las últimas versiones disponibles, especialmente del lenguaje y del framework.

Docker

Valoramos positivamente que presentes tu prueba dentro de un contenedor.

Coding Style

Valoramos positivamente que presentes un coding style consistente y especialmente que lo definas explícitamente de alguna forma, por ejemplo indicandolo en el README.md o incluyendo algún tipo de fichero de configuración como .php-cs-fixer.dist.php indicando tus reglas de estilo.

Alcance

Como ya he dicho anteriormente. Asegúrate de leer bien, lo que se pide. Muchos candidatos olvidan alguna pequeña cosa. Es obvio que es un despiste. Pero no dice algo bueno de ti, que seas despistado en una prueba sencilla.

Bundles

Muchos candidatos utilizan bundles de la comunidad. Valoramos positivamente que puedas usar los bundles más conocidos. Nos indica que conoces el ecosistema.

Comandos

La prueba probablemente te pida que ejecutes un sencillo comando. Evaluaremos que hagas un uso eficaz de los comandos. Valoramos que el candidato demuestre que conoce cómo funciona el componente configurando correctamente tanto los parámetros de entrada, como haciendo un uso correcto de la salida.

Formularios

Valoramos que el candidato demuestre que entiende bien cómo funcionan, que sea capaz de crear un formulario y añadirle algunas validaciones.

Doctrine

Valoramos que el candidato entienda cómo funciona doctrine. Declare entidades, repositorios y realice algunas queries sin cometer errores.

Servicios

Aunque la prueba no lo pide expresamente, se valora que el candidato trate de crear servicios y llevar la lógica desde los controladores a estos.

Assets / Frontend

Se valora que el candidato haga un uso correcto de webpack o que incluya algún otro recurso de frontend.

Pruebas

Se valora que el candidato entregue una batería de pruebas de algún tipo, unitarias, funcionales y sea capaz de justificar en el README.md su elección.

¿Qué te ha parecido?

Por supuesto, queremos saber tu opinión, ¿qué te ha parecido la prueba y el proceso en general?, ¿hay algo que cambiarías? ¿Crees que has tenido la oportunidad de demostrar tus capacidades? ¿Qué te hubiera gustado poder hacer?

Este es un anuncio para trabajar en: STRONGHOLD ASSET MANAGEMENT.

STRONGHOLD ASSET MANAGEMENT (SAM) es un fondo de inversión donde nos dedicamos a financiar operaciones de desarrollo inmobiliario. Es decir somos el socio capitalista para un promotor que quiere construir por ejemplo una promoción de chalets. SAM por lo tanto es una empresa a medio camino de una FINTECH y una PROPTECH. Puedes curiosear la web https://strongholdam.com/ para entender un poco mejor qué es lo que hacemos.

Un poco de historia

En torno al año 2016 Matt Calner, nuestro socio director, llegó a Madrid procedente de Londres, con la intención de establecerse en Madrid. Según sus propias palabras, la mejor ciudad del mundo.

Una vez aquí se dio cuenta de que existía una posibilidad de negocio ya que había dificultades para obtener financiación inmobiliaria. Había producto, había mercado, pero el principal freno era la financiación. Y con esta idea en la cabeza y espíritu emprendedor, se asoció con algunos inversores, conocidos y amigos, y empezaron a hacer operaciones pequeñas, principalmente préstamos puente y reestructuraciones de deuda.

En el año 2019 se fundó oficialmente SAM y en 2020 entró como socio de referencia Goldman Sachs, los que financian al FC Barcelona, con una línea de crédito de 100 millones que ha ido incrementando con el paso del tiempo.

Dentro de este camino de maduración de la compañía, a mediados del año 2020 nos contactan para desarrollar una plataforma que les ayude en su trabajo diario. Calculo de intereses, generación de certificados, gestión documental, etc. Lo que sería un pequeño proyecto de solo unos pocos meses nos llevó a finales del 2021 a incorporarnos a tiempo completo en la compañía.

Momento clave

Durante el 2021, con una plantilla realmente pequeña hemos sido capaces de financiar proyectos por un importe de más de 120 millones de euros y el objetivo es poder duplicar esa cifra cada año. Creemos que es un momento clave para los objetivos de la compañía, y queremos que nos ayudes a materializarlos.

¿Qué cosas tenemos en mente?

Estas entre otras cosas es lo que queremos hacer en el medio plazo.

• Continuar mejorando y optimizando las herramientas y procesos de la plataforma que ya tenemos.
• Mejorar la inteligencia de negocio para ofrecer información útil en tiempo real.
• Internacionalizar la compañía.

A nivel de IT nos gustaría.

• Mejorar nuestras habilidades para producir código cada vez más confiable, sostenido por una buena test suite, y que se pueda ampliar / modificar fácilmente.
• Innovar añadiendo nuevas piezas a nuestra infraestructura.

¿Qué vas a hacer?

En tus primeros días

• Conocer a tus compañeros, familiarizarte con el entorno de trabajo y el código que ya tenemos desarrollado.
• Comenzar a asimilar toda la terminología / conocimiento que necesitarás para desarrollar tu trabajo.
• Resolver algunas issues sencillas.

En algunas semanas

• Resolver issues que requieran un mayor conocimiento del proyecto.
• Gestionar tu trabajo diario, desde la toma de requisitos, hasta poner el código en producción.

En algunos meses

• Ayudar a definir y ejecutar la estrategia de IT, en base a los objetivos y necesidades de la compañía. SAM es una empresa orientada a resultados.
• Formar al equipo en aquello que creas que puedes aportar.

¿Con que lo harás?

• La pieza principal de la arquitectura está desarrollada en un monolito sobre Symfony 5.4 y PHP 8.1
  • Nos preocupan los principios SOLID y el contenido del libro CLEAN CODE, aunque no somos talibanes.
  • Tenemos test funcionales ( smoke test ) + test unitarios, que se ejecutan además de en local, en un entorno de integración continua.
• Un poquito de javascript + bootstrap.
• git + github.

¿Cómo es el equipo?

Serás el tercer compañero de un pequeño equipo de IT. Somos un equipo horizontal, autónomo y ágil. Tenemos total libertad para hacer lo que queramos.

Alvaro Cebrián

Apasionado de la tecnología y la informática, le encanta probar todo tipo de tecnologías y lenguajes nuevos que van saliendo. Aunque a nivel profesional está más enfocado en el desarrollo web, también le divierte programar mis aplicaciones de escritorio, en otros lenguajes como C o aplicaciones móviles para Android.

• https://www.linkedin.com/in/alvarocebriangarcia/
• https://github.com/alvarocebrian

Daniel González

Cree que nada es imposible si se hace con pasión y honestidad.

• https://www.linkedin.com/in/desarrolla2/
• https://github.com/desarrolla2

¿Qué buscamos?

Indispensable

• Experiencia consolidada en las todas o casi todas las siguientes tecnologías.
  • PHP, Symfony, MySQL, Git, Linux, JavaScript, Bootstrap.
• Sólidos conocimientos de programación.
  • Principios SOLID, test unitarios y funcionales.
• Capacidad para entender y proponer soluciones a problemas de negocio. No nos pagan por resolver issues, nos pagan por ayudar a la compañía a llegar al siguiente nivel.
• Alto rendimiento en el día a día, somos un equipo pequeño, pero muy productivo.

Interesante

• Conocimientos en el mundo financiero y/o del mercado inmobiliario.
• Analítica de datos.
• Comunicación en inglés.
• Docker.

¿Qué ofrecemos?

• Lo básico
  • Contrato indefinido / 23 días de vacaciones / flexibilidad horaria.
  • 100% remoto, o si lo prefieres puedes venir a nuestra oficina en Castellana 60, Madrid.
  • 40k - 70k brutos anuales.
• Otros perks:
  • Formación continua.
  • Cheques restaurante / guardería / transporte / seguro médico.
  • Viaje anual de toda la compañia. Viaje a una conferencia del equipo de IT.

¿Quieres participar?

Si estas interesad@ ¡Queremos crecer junt@s!.

aplica aquí

En esta entrada queremos explicarte algunas de las buenas prácticas que implementamos en el equipo.

CÓDIGO LIMPIO

Cuando hablamos de código limpio nos referimos a buenas prácticas en el desarrollo de software descritos por Robert C Martin en su libro “Código Limpio”, del que puedes encontrar mucha información en esta serie de entradas que hemos publicado.

El seguimiento de las indicaciones que se aportan genera proyectos que son más fáciles de mantener en el tiempo.

PROGRAMACIÓN EN PAREJAS

La programación en parejas es un concepto propuesto por Ken Beck en su libro “Programación extrema”. La idea que subyace detrás de su propuesta es que si bien, dos programadores que trabajan juntos van a producir menos líneas de código, el que generen será de mayor calidad, por lo que de forma efectiva el equipo va más rápido.

Nosotros implementamos una versión de lo que él propone. Cada programador trabaja de forma independiente la mayoría del tiempo, pero programamos por parejas cuando alguien necesita ayuda o está tocando algo muy delicado.

PRUEBAS AUTOMÁTICAS

Las pruebas automáticas es un software diseñado para probar el software, valga la redundancia, en el que se está trabajando.

El uso de pruebas automáticas añade muchas ventajas al desarrollo, pero sobre todo la principal ventaja desde el punto de vista del cliente es un producto digital con menos errores y con mayor facilidad para ser modificado.

INTEGRACIÓN CONTINUA

Integración continua es una práctica muy relacionada con el desarrollo ágil, según la cual la batería de pruebas se ejecuta de manera automática en un servidor remoto con cada cambio en el código.

RESUMEN

Diseño original

Una historia habitual que seguro que te suena conocida es que viene la persona responsable de definir la funcionalidad del producto o proyecto y te explica que necesita un nuevo módulo.

Este es una situación que no suele gustar mucho a los desarrolladores. En seguida nos ponemos a definir modelos, entidades, servicios, eventos, y todo encaja en nuestra cabeza. Pero problemente al cabo de pocos días o semanas, ese modelo no encaja todo lo bien que habíamos pensado. Puede ser porque los requisitos han ido avanzando, o simplemente por que tu diseño no se ajustaba tan bien cómo parecía.

Esta es la situación más habitual del mundo, ¿pero qué hacemos ahora?. Muchos desarrolladores introducen una pequeña ñapa para salir del paso, ponen la tarea en "done" y a otra cosa.

Los boy scouts

Los boy scouts es una asociación juvenil que tiene grupos por todo el mundo y que trata de promover una serie de valores entre los que se encuentran el cuidado del medio ambiente.

Los boy scout tienen una sencilla regla: “Siempre deja el lugar de acampada más limpio que como lo encontraste”.

Es decir, que deberías recoger y limpiar todo lo que ensuciaste tu, pero además si puedes aprovechar y limpiar alguna cosa más, dejarás el sitio en mejores condiciones para el que venga detrás de ti.

El código y la mejora continua

Como ya te habrás podido imaginar, la regla del boy scout aplicada al desarrollo de software consiste en que cada vez que tocas una pieza de código para añadir o modificar una funcionalidad, deberías mirar un poco alrededor, para ver si puedes dejar ese código un poco mejor de lo que te encontraste.

¿Quizá puedas elegir un nombre mejor para algo? ¿Quizá puedas extraer un método? ¿Quizá puedas separar responsabilidades?

No se trata de dejar tirar todo el trabajo que hay echo cada vez, si no de ir introduciendo pequeñas mejoras. Como podrás imaginarte estas pequeñas mejoras introducidas de forma continua no sólo generan una mejora gradual de la base de código, si no que ayudan a cohesionar a todo el equipo.

La academia es una iniciativa sin ánimo de lucro en la que tratamos de construir una comunidad de personas que quieren mejorar sus capacidades como desarrolladores. Cada semana enviamos un nuevo video de unos 5 minutos con técnicas, trucos y consejos relacionados con el desarrollo de software y las buenas prácticas. Si esto te resulta interesante, al final de esta entrada tienes un formulario para apuntarte.

Además ocasionalmente sorteamos algunos libros entre los miembros de la academia. Si quieres participar en este sorteo, tan sólo tienes que inscribirte y activar tu cuenta antes del día 18 de Octubre a las 23:59.

En esta entrada se describen las bases y los resultados del sorteo de tres ejemplares del libro clean code que realizaremos los días 19 de Octubre de 2020 y sucesivos, hasta que aparezca un ganador.

Premio

Se van a sortear tres ejemplares del libro clean code publicado en el año 2008 por Robert C Martin. Nos pondremos en contacto de forma privada con los ganadores.

Sorteo

• Cada usuario recibe un correo semanal, con un video relacionado con el desarrollo de software. En el píe de dicho correo mismo aparece su id de usuario.
• Se consideran usuarios activos aquellos, que han completado el formulario de registro y han confirmado su dirección de correo electronico.
  • Los id de usuario activos en el momento de realizar el sorteo son los siguientes: 001, 006, 008, 009, 010, 013, 014, 015, 016, 017, 019, 021, 022, 023, 024, 025, 026, 027, 028, 029, 031, 034, 035, 036, 037, 038, 039, 040, 041, 042, 043, 044, 045, 046, 047, 048, 049, 050, 051, 052, 053, 054, 055, 058, 060, 061, 066, 067, 069, 070, 071, 072, 073, 074, 075, 077, 078, 079, 080, 081, 084, 085, 086, 087, 090, 091, 092, 093, 094, 095, 096, 098, 099, 101, 103, 104, 105, 106, 107, 108, 110, 112, 113, 114, 115, 117, 118, 119, 121, 122, 123, 124, 125, 126, 127, 128, 130, 131, 134, 135, 136, 137, 138, 139.
• Los números se obtendrán del sorteo del cupón diario de la once, siendo el primer resultado válido el sorteo del día 19 de Octubre de 2020.
  • Si el id es menor que 100 resultarás ganador con los resultados pares de las centenas. Por ejemplo el id 001, resultará ganador con el 001, 201, 401, 601 y 801.
  • Si el id es superior a 100 resultarás ganador con los resultados impares de las centenas. Por ejemplo el id 101, resultará ganador con el 101, 301, 501, 701 y 901.
• Si un resultado no se corresponde con ninguno de los ids activos, se utilizará el resultado del día siguiente.
• Gastos de envío.
  • Si se puede enviar sin gastos de envío via amazon prime se enviará sin gastos de envío.
  • Si no se puede, se le pedirán al destinatario que se haga cargo de los gastos de envío o se pasará al resultado del día siguiente.
• El sorteo continuará hasta que tengamos tres ganadores.

Resultados

Elige tu estilo

En mi opinión no tan importante que reglas utilices para organizar tus clases. Lo que sí es muy importante, es que elijas unas y te comprometas con ellas. También es muy importante que no seas dogmático y que estés dispuesto a añadir o modificar tus reglas si es que aparecen otras mejores.

No hay nada más frustrante que tratar de explicar a un desarrollador una forma mejor de hacer las cosas, y que no sea capaz de salir de sus trece, pero que tampoco sea capaz de argumentar un motivo.

Dentro de las reglas que elijas ten en cuenta que nada debe quedar al azar, si no que se note que todo está de una forma determinada por un motivo determinado y no simplemente por que ha quedado así.

Nuestro estilo

Nosotros utilizamos la guia de estilo oficial para symfony ya que es el framework con el que trabajamos. Además es muy sencillo configurar el editor para que las aplique automáticamente.

A continuación vamos a explicar el resto de reglas que utilizamos nosotros y que no son exactamente iguales a las que describe el autor en el libro. Pero que vamos a argumentarte los motivos que hemos tenido en cuenta para elegirlas.

Para ello vamos a analizar la clase Rectangle que ya conocemos de entradas anteriores.

Casi todo lo que vamos a ver son esos pequeños detalles que forman parte de nuestra política de no dejar nada al azar, y que probablemente no supongan una gran diferencia por sí sólos, pero que en conjunto y adoptadas por todo el equipo, nos permiten generar una base de código de calidad en todos nuestros proyectos.

Vamos a describir las reglas leyendo la clase de arriba a abajo.

Cabecera

La cabecera es normalmente un fragmento de código comentado que se pone encima de cada fichero. Debería indicar a que proyecto pertenece, que tipo de licencia aplica y que personas han intervenido en ella.

Lo más habitual es utilizar alguna herramienta para asegurar que todos los ficheros tienen la cabecera correcta y esta está actualizada a la última versión.

/*
 * This file is part of the clean code example package.
 *
 * Copyright (c) 2016-2020 Devtia Soluciones.
 * All rights reserved.
 *
 * @author Daniel González <daniel@devtia.com>
 */
final class Rectangle
{
    //..
}

La definición de la clase

Nosotros intentamos por defecto ser lo más restrictivos posible, y luego ir abriendo la visibilidad según sea necesario. Por eso siempre declaramos nuestras clases por defecto como final. Una palabra reservada que nos permite indicar que la clase no puede extenderse.

Las constantes de clase

Nosotros habitualmente separamos las constantes en clases independientes. Por ejemplo, si quisiéramos poner los colores como constantes, es mejor crear una clase diferente para contenerlos. De esta forma mejoramos la semántica del dominio.

final class Color
{
    const WHITE = 'FFFFFF';
    const BLACK = '000000';
}

Atributos

Como norma general declaramos todos atributos como private. Si fuera necesario cuando realizamos un diseño, algunos de estos los declaramos como protected y evitamos siempre los atributos public salvo cuando se trata de DTOs.

Si tenemos atributos de diferente visibilidad dentro de una clase los agrupamos según su visibilidad.

Dentro de cada grupo, ordenamos los atributos por orden de importancia. Los más importantes arriba. También tratamos de agruparlos por tipo, para que estén todas las fechas juntas, todos las colecciones juntas, ...

final class Rectangle
{
    /* @var Point */
    private $topLeft;

    /** @var Color */
    private $backgroundColor;

    /** @var Color */
    private $borderColor;

    /* @var float */
    private $border;

    /* @var float */
    private $height;

    /* @var float */
    private $width;

    //..
}

El constructor y el resto métodos mágicos

A continuación de los atributos escribimos el constructor de la clase. Una clase no debería encontrarse en una situación inconsistente. Por eso el constructor debería recibir todo aquello que la clase necesita para existir. De esta forma evitamos por ejemplo la existencia de un Rectangle cuya altura está sin definir.

final class Rectangle
{
    //..
    public function __construct(Point $topLeft, float $height, float $width)
    {
        $this->topLeft = $topLeft;
        $this->height = $height;
        $this->width = $width;
    }
    //..
}

Los metodos mágicos son métodos que están definidos para todas las clases en php, y que son invocados cuando ocurre una circustancia concreta. Nosotros los definimos por orden alfabético después del constructor.

Los métodos públicos

Nosotros ordenamos los métodos agrupándolos por visibilidad. Arriba del todos los métodos public luego todos los protected y finalmente todos los private.

El autor nos indica que se deberían ordenar según su importancia y mantener los métodos relacionados cerca entre sí. Nosotros creemos que esto podría tener sentido en el momento de publicar el libro, pero es una regla dificil de aplicar, cuando por ejemplo un mismo método se llama desde diferentes métodos, ¿junto a cual lo pones?

Los editores modernos nos permiten navegar con facilidad entre métodos aúnque no estén cercanos entre sí, asi que nosotros simplemente los ordenamos alfabeticamente y configuramos el editor para que haga esto automáticamente por nosotros.

El resto de métodos

Los métodos que no son public deberían declararse private a menos que exista una buena razón para ello. Los ordenamos también por orden alfabético y dejamos que el editor se encarge de esta tarea.

Bloques de código

Para explicar esto es necesario traer un ejemplo un poco más complejo. Veamos un ejemplo real de uno de nuestros proyectos.

final class ProposalController extends AbstractProposalController
{
    //..
    public function copyAction(Project $proposal)
    {
        $this->throwNotFoundExceptionIfNotIsPublicProposal($proposal);

        $copyManager = $this->get('app.service.project_copy_manager');
        $publicProposal = $copyManager->generatePublicProposal(
            $proposal,
            null,
            \AppBundle\Entity\Project\Type::PUBLIC_PROPOSAL_CLIENT_VERSION
        );

        $manager = $this->get('app.service.project_manager');
        $manager->update($publicProposal);

        $this->addFlash('success', 'proposal successfully updated');

        return $this->redirectToRoute('_public.proposal.view', ['hash' => $publicProposal->getHash()]);
    }
    //..
}

Si ves el ejemplo anterior puedes ver que cada concepto está separado por un salto de línea. Lo primero que hacemos es la validación o cláusulas de guarda, de las que hablaremos en otra entrada más adelante.

Lo siguiente que hacemos es obtener una copia de la propuesta a través del servicio correspondiente. Después actualizamos esa copia, mensaje de éxito y redirección a la nueva propuesta.

Cada concepto está separado por un salto de línea facilitando su entendimiento al lector.

Ni un salto de línea de más

El último detalle. Ya hemos visto donde sí debemos poner un salto de línea. En nuestra opinión no se deben añadir saltos de línea adicionales, porque dan la sensación de estar ahí por que sí, en lugar de porque tienen que estar.

¿Pruebas automáticas?

Las pruebas o la batería de pruebas es un software que debe escribirse en paralelo a nuestro propio software y cuya responsabilidad es comprobar que nuestro software funciona correctamente. Básicamente es software que prueba nuestro software.

Puede que intuitivamente pienses que construir una batería de pruebas, es trabajo adicional, ya que probablemente tardarás más tiempo y por lo tanto tu trabajo será más caro para tus clientes pero esto no es así.

Cuando tienes una buena batería de pruebas, la primera "derivada" es que vas a cometer menos errores. Menos errores supone menos tiempo arreglando errores y más tiempo programando. Además supone menos frustración en los usuarios.

La segunda derivada es que puedes hacer cambios con mayor confianza, y esto te hace ir más rápido. Las pruebas detectarán que has roto, y simplemente tendrás que arreglarlo, un equipo con una buena batería de pruebas termina trabajando mucho más rápido que un equipo que no las tiene.

Hay una tercera derivada y es que al desarrollar tu batería de pruebas te va a permitir diseñar mejor software, pero esto es algo en lo que profundizaremos en una entrada más adelante.

¿Si es tan bonito por que no todo el mundo hace pruebas automáticas?

Cuando escribes pruebas debes ser tan cuidadoso cómo con el código de producción. Todo lo que hemos comentado ya en esta serie sobre elegir buenos nombres, funciones, argumentos, etc son cosas que también aplican a las pruebas automáticas.

Escribir buenas pruebas requiere cierta técnica y ocurre que muchos programadores o equipos comienzan haciendo pruebas, y al no ser pruebas de calidad terminan teniendo una batería de pruebas que supone más un problema que una solución. Tras esta mala experiencia desisten, por eso en esta entrada vamos a explicarte cómo escribir buenas pruebas.

Escribe tus pruebas "PRIMERO"

FIRST o PRIMERO es un acrónimo que se utiliza para describir las características que debería tener una prueba.

Fast o Rápidas

Una prueba, así como la batería de pruebas a la que pertenecen deberían ser tan rápidas cómo sea posible. ¿Cuánto? Pues depende del tipo de prueba y del proyecto. El autor no se moja en este aspecto, pero en mi opinión deberías mantener cada prueba por debajo de 1 segundo.

Independent o independientes

Unas pruebas no deberían depender de otras. Esto te permitirá ejecutar aisladamente las pruebas que fallen en lugar de tener que ejecutar toda la batería o un conjunto de pruebas.

Repeatable o repetibles

El resultado de una prueba debería ser siempre el mismo y no variar si la ejecutas varias veces. De esta forma, podrás ejecutar una prueba una y otra vez, hasta que arregles el error. De lo contrario tendrías continuamente errores que luego no vas a poder reproducir.

Self-validating o validación automática

Lo que quiere decir esta regla es que las pruebas no deberían depender de una revisión, por ejemplo que el resultado fuera un texto que luego necesitarás leer para saber si es correcto o no. La prueba debe pasar o no pasar, no debería haber otro resultado posible.

Timely o en el momento correcto

El autor introduce en este capítulo las reglas del ciclo de TDD: rojo, verde y refactorización, pero no quiero profundizar mucho sobre este aspecto aquí, porque tendremos el libro "Test Driven Development: By Example" por en este blog y en el canal de youtube más pronto que tarde.

Show me the code

Supongamos que tenemos la clase rectangulo que vimos en el capítulo de estructuras vs objetos.

class Rectangle
{
    private $height;
    private $width;

    public function __construct(float $height, float $width)
    {
        $this->height = $height;
        $this->width = $width;
    }

    public function area(): float
    {
        return round($this->height * $this->height, 2);
    }
}

Escribir una prueba es una tarea muy sencilla, normalmente es simplemente una clase que tiene que extender de algún tipo de framework de pruebas, así es como se hace con phpunit

class RectangleTest extends \PHPUnit\Framework\TestCase
{
    public function test_area()
    {
        $rectangle = new Rectangle(1.11, 2.22);
        $this->assertSame(2.46, $rectangle->area());
    }
}

Fácil, pero ¿que ocurre al ejecutarlo?

Efectivamente había un error en el código. En este caso lo hemos introducido a posta, pero es un tipo de error que se puede cometer fácilmente.

¿Has visto cual?

Veamos un ejemplo con la clase responsable de notificar a los usuarios de la academia que hay un nuevo contenido disponible. En el método send recibiremos un usuario y la entrada que debe serle notificada.

Partiremos de este primer ejemplo donde la gestión de errores ensucia el código para ver cuales son las diferentes mejoras que podemos ir realizando.

class SendCommand extends AbstractCommand
{
    private function send(User $user, Post $post): void
    {
        $code = $this->mailer->sendTemplate(
            [$user->getEmail() => $user->getName()],
            $post->getName(),
            '@App/Command/Academy/Mailing/Post/post.html.twig',
            [
                'user' => $user,
                'post' => $post,
            ]
        );

        if (Code::TIMEOUT == $code) {
            sleep(20);
            $this->send($user, $post);
        } elseif (Code::ADDITIONAL_DATA_REQUIRED == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because was unavailable',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } elseif (Code::ADDITIONAL_DATA_REQUIRED == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because additional space was needed',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } elseif (Code::INBOX_IS_FULL == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because the inbox was full',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        }
    }
}

Como se puede ver este ejemplo inicial tiene bastante que mejorar.

Evita utilizar códigos de error

Los códigos de error son difíciles de manejar. En general van a requerir un montón de estructuras if / else para poder lidiar con los diferentes códigos de error.

Además siempre cabe la posibilidad de que se añada un nuevo código de error que nosotros no tengamos capturado. En lugar de códigos de error sería conveniente utilizar excepciones.

A continuación vemos exactamente el mismo código pero utilizando excepciones:

class SendCommand extends AbstractCommand
{
    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(
                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (TimeoutException $e) {
            sleep(20);
            $this->send($user, $post);
        } catch (AdditionalDataRequiredException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because was unavailable',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } catch (ServiceUnavailableException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because additional space was needed',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } catch (InboxIsFullException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because the inbox was full',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        }
    }
}

De momento no hemos mejorado mucho y nuestro código sigue teniendo una pinta terrible, pero estamos un paso más cerca de tener nuestro código bastante más elegante.

Separar lógica y gestión de errores

Lo que vamos a hacer ahora es separar la responsabilidad en dos métodos. Uno de ellos contendrá la lógica de negocio y el otro contendrá la gestión de errores. Este sencillo cambio hace nuestro código mucho más legible y fácil de mantener.

class SendCommand extends AbstractCommand
{
    private function handleSendException(User $user, Post $post, \Exception $exception): void
    {
        try {
            throw $exception;
        } catch (TimeoutException $e) {
            // ..
        } catch (AdditionalDataRequiredException $e) {
            // ..
        } catch (ServiceUnavailableException $e) {
            // ..
        } catch (InboxIsFullException $e) {
            // ..
        }
    }

    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(
                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (\Exception$exception) {
            $this->handleSendException(user, $post, $exception);
        }
    }
}

Evita los detalles de implementación

Nuestro código ha mejorado bastante, pero todavía tiene un problema. Nuestro comando conoce los detalles de implementación del sistema de envío de correo. Esto supone un problema, si en el futuro quisiéramos enviar el correo o las notificaciones con otra librería o a través de otro medio, nuestro comando dejaría de funcionar.

Para ello es conveniente evitar conocer los detalles de implementación ( las excepciones ) que contiene el sistema de envío, con lo que nos debería quedar algo así.

class SendCommand extends AbstractCommand
{
    private function handleSendException(User $user, Post $post, \Exception $exception): void
    {
        $this->log(
            sprintf(
                'message [%06d] for user "%s" with message "%s"',
                $post->getId(),
                $user->getEmail(),
                $exception->getMessage()
            )
        );
    }

    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(

                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (\Exception$exception) {
            $this->handleSendException($user, $post, $exception);
        }
    }
}

Empezemos describiendo los motivos por los que no deberías hablar con extraños: muchas veces cuando tenemos una clase que a su vez está formada por objetos de otras clases y estas a su vez por otras, tenemos una estructura de clases. Hasta aquí todo bien, pero: ¿qué ocurre cuando estas estructuras se vuelven complejas? Veamos un ejemplo que podría darse en un comando de symfony.

class CustomCommand extends Command
{
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $this->getApplication()->getKernel()->getContainer()->getCustomService()->getManager()->execute();

        return 1;
    }
}

Como puedes ver, estamos acoplando de forma innecesaria nuestro código a todas las clases que aparecen en la cadena de llamadas. Cualquier cambio en estas clases o en las relaciones entre ellas podría suponer que nuestro código dejase de funcionar. Para que esto no suceda viene al rescate la ley de demeter.

La ley de demeter

La ley de demeter fue descrita por primera vez dentro del proyecto demeter en 1987. Como curiosidad quiero contarte que Demeter, hace referencia a la diosa griega de la agricultura. Querian hacer referencia a algo así como "cultivar" software en contraposición a "construir" el software.

La ley indica que desde un método solo deberías "hablar" con aquellos a quien conozcas bien. Y estos son:

• Métodos de la misma clase.
• Métodos de los objetos de la clase.
• Métodos de los objetos creados en la misma función.
• Métodos de los objetos pasados como argumento a la función.

¿Y cómo lo soluciono?

Ya hemos detectado que es lo que no debes hacer, te voy a proponer ahora tres opciones a tener en cuenta cuando detectes este problema en tu código.

No hacer nada

La primera es no hacer nada. Es la solución más sencilla, y la peor de las tres que vamos a ver, pero como ya vimos en la entrada sobre los dogmas en el desarrollo de software, si crees que las clases que estás llamando y sus relaciones están muy consolidadas, podrías permitirte el lujo de realizar este tipo de llamadas en cadena.

Usar atajos

La segunda consiste en hacer atajos que permitan evitar estas llamadas encadenadas. Esta es una solución bastante rápida, que te puede permitir salir del paso en algún momento.

Por ejemplo en CustomService podríamos añadir el método executeManager.

class CustomService
{
    public function executeManager(): void
    {
        $this->getManager()->execute();
    }
}

Esta solución como puedes imaginarte tampoco es la mejor. Te permite abstraer parte de esa cadena de llamadas y por lo tanto es una opción mejor que al principio, ya que si la relacion cambia sólo tendrás que cambiar en este punto las llamadas.

El problema de esta solución es que puedes encontrarte con tu código con un montón de estos métodos atajos, que realmente por diseño no deberían encontraser ahí, pero están simplemente para hacer cumplir la ley de demeter.

Inyectar dependencias

La solución buena, como probablemente ya te venías imaginando es inyectar las dependencias. Veamos un ejemplo.

class CustomCommand extends Command
{
    public function setCustomManager(CustomManager $customManager)
    {
        $this->manager = $customManager;
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $this->manager->execute();
    }
}

Hemos añadido como dependencia la clase CustomManager que era la que realmente necesitamos, y se la hemos inyectado a través de un setter, pero hemos eliminado toda la cadena de dependencias y las relaciones entre sí.

Con este sencillo cambio hemos podido eliminar fácilmente todas las dependencias sobrantes.

Estructuras de datos

Una estructura de de datos, es una clase o un objeto que expone la información que contiene. En el ejemplo hemos evitado el uso de getters y setter, pero sería exactamente lo mismo si los tuviera, lo consideraremos una estructura, porque expone su información. Otras clases serán responsables de realizar las funcionalidad que necesitemos.

class Circle
{
    /** @var Point */
    public $center;
    public $radius;
}

class Geometry
{
    const PI = 3.141592653589793;

    public function area($shape): float
    {
        return $shape->radius * $shape->radius * Geometry::PI;
    }
}

Objetos

Con el mismo ejemplo si usaramos el paradigma de la orientación a objetos, debemos ocultar cuál es la información y la estructura de los datos internos, y debemos exponer la funcionalidad que queremos.

class Circle
{
    const PI = 3.141592653589793;

    /** @var Point */
    private $center;
    private $radius;

    public function area(): float
    {
        return $this->radius * $this->radius * self::PI;
    }
}

Aunque el ejemplo es muy sencillo nos permite entender la diferencia. Una estructura de datos es un elemento sencillo que solamente contiene información, mientras que la lógica se encuentra en otras clases. Un objeto es una abstracción que expone su funcionalidad.

Añadir nuevas estructuras de datos / objetos

Vamos añadir un nuevo tipo: Rectangle y vemos a ver que cambios son necesarios en cada aproximación.

class Rectangle
{
    /** @var Point */
    public $topLeft;
    public $height;
    public $width;
}

class Circle
{
    /** @var Point */
    public $center;
    public $radius;
}

class Geometry
{
    const PI = 3.141592653589793;

    public function area($shape): float
    {
        if ($shape instanceof Rectangle) {
            return $shape->height * $shape->width;
        }

        if ($shape instanceof Circle) {
            return $shape->radius * $shape->radius * Geometry::PI;
        }

        throw new InvalidArgumentException();
    }
}

class Rectangle
{
    /** @var Point */
    private $topLeft;
    private $height;
    private $width;

    public function area(): float
    {
        return $this->height * $this->width;
    }
}

class Circle
{
    const PI = 3.141592653589793;

    /** @var Point */
    private $center;
    private $radius;

    public function area(): float
    {
        return $this->radius * $this->radius * self::PI;
    }
}





    

¿Que diferencia ves entre ambos?. En la primera aproximación además de añadir la nueva estructura, hemos tenido que modificar Geometry::area(). En el ejemplo es un cambio muy sencillo, pero nos sirve para identificar que cuando añadimos nuevas estructuras vamos a tener que revisar el código que las utiliza para que sea capaz de manejar esta nueva estrucutra, lo cual nos puede llevar a añadir errores en un códiugo que ya estaba funcionando.

En cambio en la aproximación orientada a objetos no hemos tenido que modificar ni una coma del código que ya teníamos, y simplemente hemos tenido que añadir un nuevo objeto.

Añadir funcionalidad

Vamos a añadir una nueva funcionalidad, el cálculo del perímetro: perimeter a ver que tal se comporta cada una de nuestras implementaciones.

class Rectangle
{
    /** @var Point */
    public $topLeft;
    public $height;
    public $width;
}

class Circle
{
    /** @var Point */
    public $center;
    public $radius;
}

class Geometry
{
    const PI = 3.141592653589793;

    public function area($shape): float
    {
        if ($shape instanceof Rectangle) {
            return $shape->height * $shape->width;
        }

        if ($shape instanceof Circle) {
            return $shape->radius * $shape->radius * Geometry::PI;
        }

        throw new InvalidArgumentException();
    }

    public function perimeter($shape): float
    {
        if ($shape instanceof Rectangle) {
            return 2 * $shape->height + 2 * $shape->width;
        }

        if ($shape instanceof Circle) {
            return 2 * Geometry::PI * $shape->radius;
        }

         throw new InvalidArgumentException();
    }
}

class Rectangle
{
    /** @var Point */
    private $topLeft;
    private $height;
    private $width;

    public function area(): float
    {
        return $this->height * $this->width;
    }

    public function perimeter(): float
    {
        return 2 * $this->height + 2 * $this->width;
    }
}

class Circle
{
    const PI = 3.141592653589793;

    /** @var Point */
    private $center;
    private $radius;

    public function area(): float
    {
        return $this->radius * $this->radius * self::PI;
    }

    public function perimeter(): float
    {
        return 2 * self::PI * $this->radius;
    }
}








    

En este caso, nuestra primera aproximación ha sido más sencilla. No hemos tenido que tocar el código que ya teníamos funcionando y sólo hemos tenido que añadir una nueva función.

En cambio en la aproximación orientada a objetos hemos tenido que tocar cada una de las clases que teníamos para añadirles esta funcionalidad. El ejemplo es muy sencillo, pero nos sirve para identificar el problema.

Conclusiones

A nivel de líneas de código no existe una diferencia sustancial. Tampoco es razonablemente más sencillo de implementar o de mantener una u otra aproximación, pero cuando utilizamos estructuras, tendremos cierta facilidad cuando queramos añadir nueva funcionalidad, mientras que cuando utilizamos objetos tendremos facilidades para añadir nuevos tipos.