Testing expresivo
Desde hace un tiempo estoy explorando una forma de organizar el código de mis tests, al menos de una parte de ellos. A falta de un nombre mejor he decidido llamar a esta organización testing expresivo.
A blog about programming, mainly PHP, and maybe other things
Desde hace un tiempo estoy explorando una forma de organizar el código de mis tests, al menos de una parte de ellos. A falta de un nombre mejor he decidido llamar a esta organización testing expresivo.
La Standard PHP Library incluye unas cuantas clases que merece la pena conocer, entre ellas SplFileObject de la cual nos ocupamos en este artículo. Sin embargo, a veces tienen alguna sorpresa oculta.
En anteriores entregas hemos propuesto refactorizar código a Value Objects o aplicar principios como la ley de Demeter o Tell, don’t ask para mover código a un lugar más adecuado. En este capítulo vamos a analizarlo desde un punto de vista más general.
En el blog ya hemos hablado del patrón clásico Single Exit Point y cómo acabó derivando en single return. También algún momento de esta guía de refactor hemos hablado también del return early. Ahora vamos a retomarlos conjuntamente porque seguramente nos los encontraremos más de una vez.
Para ser una disciplina dedicada a que el software se comporte correctamente, lo cierto es que cuando hablamos de testing usamos el lenguaje con muy poca precisión.
En este capítulo veremos refactors basados en la redistribución de responsabilidades.
Artículo sobre antipatrones en el uso de dobles de tests y algunas heurísticas útiles para hacer buenos tests cuando necesitamos dobles.
Supongamos que te planteas introducir testing en un proyecto que no lo tiene o que no está suficientemente testeado.
Los enumerables son tipos de datos que cuentan con un número finito de valores posibles.
Recientemente he comenzado a trabajar en otro proyecto dentro de la empresa ayudando con el testing. Es una parte del negocio que conozco poco todavía y la aplicación con la que estoy trabajando es, por supuesto, distinta, aunque similar en planteamiento.
Hace unos días anunciábamos que el libro Testing y TDD para PHP estaría incluido gratis para los suscriptores de CodelyTV Pro. Ahora, además, si compras el libro tienes un 50% de descuento en el primer mes de suscripción.
Nuestro canal formativo favorito nos ha hecho una propuesta que no hemos podido rechazar.
PHP viene de serie con un conjunto de tipos de datos básicos que denominamos escalares: bool, int, float, string…, que utilizamos para representar cosas y operar con ellas. La parte mala es que son tipos genéricos y, a veces, necesitaríamos algo con más significado.
Una vez que comprendemos el concepto, no es difícil hacer TDD. Pero ese primer paso necesario para arrancar suele necesitar ayuda. Lo mejor es encontrar un ejercicio de programación que sea sencillo sin ser trivial y que ayude a poner de manifiesto los elementos más importantes de la metodología TDD.
La tercera entrega de la guía del refactor cotidiano trata sobre cómo mejorar las estructuras condicionales.
La segunda entrega de la guía del refactor cotidiano trata de los nombres y cómo mejorarlos.
Después de darle vueltas a la idea una temporada hemos agrupado varios artículos del blog sobre testing en un libro.
La primera entrega de la guía del refactor cotidiano trata sobre los comentarios.
Presentamos el primer curso/guía de The Talking Bit.
La normalización de las bases de datos es un proceso que persigue reducir la redundancia de datos y controlar las dependencias entre las entidades representadas en las tablas, de modo que éstas puedan evolucionar fácilmente y se reduzcan los errores que generen inconsistencia de datos.
A booklet with tips to refactor on a daily basis.
Aprovechando que estoy preparando material para organizar formaciones en testing, dejo aquí este resumen de técnicas básicas para seleccionar casos para probar.
Here you have some resources to help in testing and tdd workshops. Hope you will find them useful.
El operador ternario comparte con null coalescence el símbolo de la interrogación, pero ahí se acaba el parecido.
La ética es la rama de la filosofía que se ocupa del “buen vivir”. Pero no en el sentido hedonista que podrías imaginar por la expresión, sino en el sentido de la manera correcta de vivir.
Vamos a cambiar un poco de enfoque antes de continuar con otros aspectos y ejemplos técnicos del Desarrollo Guiado por Comportamiento. Vamos a ocuparnos del BDD como herramienta de comunicación.
Ya llevamos tres capítulos de esta serie sobre BBD en PHP. En el primer artículo de la serie dimos una visión general de BDD y Behat. En el segundo y el tercero revisamos el proceso de desarrollo de una Feature desde la historia de usuario hasta tener un código funcional usando la metodología y herramientas BDD.
En el primer artículo de la serie comenzamos introduciendo el concepto de BDD, el lenguaje Gherkin y la herramienta Behat. En el segundo, utilizamos phpspec para comenzar a desarrollar nuestra feature, partiendo de un Use Case y descubriendo las clases colaboradoras necesarias a medida que identificamos responsabilidades. En esta tercera entrega pretendemos a empezar a unir las piezas.
En el artículo anterior comenzamos introduciendo el concepto de BDD, el lenguaje Gherkin y la herramienta Behat. Al final del mismo, nos habíamos quedado con una feature escrita en Gherkin y un test de aceptación vinculado fallando.
Como desarrolladores nos gusta que las historias de usuario que definen nuestros Product Owners estén bien escritas, de modo que podamos implementar lo que se nos pide. Lo mejor de todo es que existe una herramienta conceptual y técnica para lograr eso.
O las aventuras de un junior de 50 años.
Aunque está entre nosotros desde la versión 5.6 de PHP, splat operator es relativamente desconocido y su uso no deja de ser un poco confuso.
Arquitectura es el análisis y diseño de la estructura, organización de los componentes y sus relaciones en un sistema de software.
Pululan por nuestras bases de código como almas en pena, transportando datos de un lugar a otro. Sin embargo, podrían dar esplendor a nuestras aplicaciones si les damos un poco de atención.
De vez en cuando nos puede interesar disponer de un log específico para una parte concreta de una aplicación. Fundamentalmente lo que pretendemos es aislar esos mensajes para poder analizarlos con facilidad.
Cada vez que necesitamos instanciar objetos en una aplicación tenemos que resolver un pequeño problema.
Acabo de desarrollar una pequeña herramienta puede ayudarte a automatizar la creación de tags de versión semántica con git.
¿Por qué razón poner nombres a las cosas se considera uno de los aspectos más difíciles de la programación?
Refactorizar es más que una tarea técnica. Refactorizar tiene valor de negocio porque su función principal es asegurar que el lenguaje y el conocimiento del negocio están reflejados en el código.
Cómo aplicar el principio de inversión de dependencias, entendiendo qué es dependencia y qué acoplamiento. ¡Ah! Y cómo saber cuándo necesitamos usar inyección o instanciación al crear objetos.
Algunas estrategias con las que intento que mis tests sean cada vez más limpios y legibles y, por tanto, más capaces de comunicar lo que hace el software que escribo.
Some key concepts explained to know what’s happening when you work with this VCS.
If/then es una de las estructuras de control básicas de la programación, pero su abuso puede multiplicar la complejidad de un algoritmo y la dificultad de mantenerlo. En este artículo exploraremos alguna estrategias para usar los if con cabeza.
Hay validadores de NIF a espuertas, pero escribir uno con TDD resulta ser un interesante ejercicio con el que desarrollar algunas estrategias de test.
Al hablar de código expresivo queremos decir no sólo que el código debería indicar con claridad su intención, también queremos que el código revele más cosas de sí mismo.
Mi primer contacto con los tests, con el propio concepto de test para ser precisos, fue de todo menos una epifanía.
Este es un artículo rescatado del olvido. Lo escribí en 2010, como forma de aprender el funcionamiento de las uniones de tablas en SQL.
¿Cómo testear lo que no podemos predecir? En muchos sentidos los tests se basan en que el comportamiento del código es predecible: si hacemos ciertas operaciones con ciertos datos podemos esperar ciertos resultados y no otros. Pero esto no siempre se cumple, a veces tenemos que testear algo que no sabemos qué será.
Estos últimos días he trabajado bastante con el patrón Builder, así que toca escribir algo sobre su utilidad para la creación de objetos complicados.
Los principios de diseño están muy relacionados con el testing de tal forma que son tanto objetivo de diseño como herramienta para lograrlo.
Estaba pensando en comenzar el artículo con la manida metáfora de los test doubles como especialistas de cine, los que doblan a los actores en ciertas escenas, no necesariamente peligrosas. Pero cuando más vueltas le doy, menos claro tengo que sea un buen símil.
Ya han pasado más de siete meses desde que llegué a Barcelona, acabo de cumplir mis dos primeras semanas en una nueva empresa y estoy muy contento en mi nuevo equipo, con quienes ya he empezado a aprender un montón de cosas y, de paso, desoxidarme un poco.
Las excepciones son elementos del lenguaje que nos permiten indicar situaciones que rompen el flujo normal de un programa. Cuando se lanza una excepción, ésta asciende la pila de llamadas del lenguaje hasta encontrar algún punto en que sea gestionada. Si no lo encuentra, el flujo del programa se detiene y se muestra un error.
El patrón decorador tiene como objetivo permitirnos modificar el comportamiento de un objeto en tiempo de ejecución, esto es, de manera dinámica.
Si trabajas con un buen IDE puede que te quedes con la sensación de que no necesitas nada más, pero todo ayuda.
Hoy voy a hacer un experimento interesante: una kata en Pyhton. Llevo una temporada jugueteando un poco con el lenguaje y he podido probar algunas cosillas.
Hace unos días subí al repositorio una versión para PHP de la Quotebot Kata, un ejercicio propuesto por Cyrille Martraire en el que se presenta un código que inicialmente es imposible de testear (y prácticamente de ejecutar en tu local).
El code coverage es una métrica que conviene coger con pinzas y examinar con mucho cuidado.
La validación es el proceso mediante el cual nos aseguramos de que los datos introducidos al sistema cumplen ciertas condiciones necesarias para poder utilizarlos sin peligro, sin provocar errores, y con la posibilidad de proporcionar resultados, al mantenerse dentro de los límites de tolerancia de los algoritmos que los emplean.
Este artículo es una continuación del anterior sobre Código mentiroso, y en él tocaremos algunos problemas derivados del uso insuficiente de las posibilidades expresivas del lenguaje.
En esencia, el código mentiroso es todo código que dice que hace algo, pero en realidad no lo hace, o hace algo diferente, o desvía nuestra atención de algo que deberíamos saber.
En el artículo anterior quedaron pendientes algunos refactors en nuestro proyecto. En esta entrega mi intención es tratar de rematarlos, así como hacer alguna reflexión sobre los resultados obtenidos y sus consecuencias.
En el artículo anterior colé un error en la estrategia de refactoring y, antes de continuar, voy a detenerme en ese problema porque es realmente interesante.
Una vez que hemos conseguido describir con tests el comportamiento del método que nos interesa, llega el momento de refactorizar. Queremos cambiar la implementación, pero no alterar el comportamiento público del método. Por lo tanto, los tests han de permanecer en verde tras cada cambio, procurando que la fase roja dure lo menos posible, lo que implica realizar baby-steps y no grandes refactors de una sentada.
¿Qué tal si hablamos de refactor?
Terminamos con esta serie sobre la disciplina TDD en la que he aprendido un montón de cosas.
Con lo pequeñita que es la clase Collection y está dando para un montón de artículos. En esta cuarta entrega voy a intentar desarrollar el método filter, el cual también nos dará un punto de partida para otros métodos.
Ahora implementaremos pipelining, para encadenar operaciones en una colección.
Ahora que tenemos una clase Collection a la que podemos añadir objetos de un tipo determinado o sus descendientes, vamos a desarrollar algo de comportamiento. Al fin y al cabo, queremos nuestras colecciones para hacer algo con sus elementos, no sólo para admirarlas… (ejem!).
Arrays…
El último artículo me dejó con un poco de mal sabor de boca porque la solución propuesta al problema de tratar casos especiales en una colección de objetos que estábamos construyendo a partir de datos obtenidos de una API externa cojea en algún punto.
A veces tenemos que hacer cosas específicamente con algunos objetos de una colección. En este artículo planteo una forma de encarar este problema.
Los patrones se convierten en anti-patrones si los llevamos más allá de sus límites de aplicabilidad.
Tuve la suerte de asistir a la Vª Software Craftmanship de Barcelona, encuentro en el que he disfrutado y aprendido mucho y de dónde he podido sacar unas cuantas ideas interesantes.
Hace unos días trabajamos en una de esas historias que mola porque puedes reducir un poco de legacy code y refactorizar, contribuyendo a mejorar la calidad del código y su extensibilidad futura.
El patrón Strategy (estrategia) se basa en encapsular una familia de algoritmos de modo que sean intercambiables.
Existen una serie de patrones de diseño de sóftware básicos, pero nada nos impide crear nuevos patrones a partir de alguno de los clásicos, con el fin de adaptarlos a situaciones más específicas. Sencillamente, son patrones menos generales.
Mañana miércoles se cumplen dos semanas de mi nueva etapa profesional.
Llevo un tiempo volviendo a aprender Javascript y estoy empezando a entender este lenguaje. Casi hasta me gusta.
Mi historia ha tenido final feliz: a mediados de agosto me incorporo como desarrollador a una empresa genial.
En las entregas anteriores de la serie he tratado de explicar cómo hacer TDD usando PHPSpec. En esta última, voy a mostrar cómo dar un “salto” en el desarrollo, usando los test existentes como protección.
En esta tercera entrega, vamos a examinar cómo los nuevos requisitos nos pueden llevar a refactorizar una solución existente y discutiremos lo que define la sobreingeniería.
Continuamos con la kata iniciada en el artículo anterior.
Voy intentar explicar cómo empezar a hacer BDD/TDD con PHPSpec.
En esta entrega, voy a empezar a mostrar algo de código de un controlador que maneja una API.
Porque todos tenemos spaghetti apestando en el armario.
Nadie dijo que encontrar trabajo como desarrollador PHP fuese fácil, mucho menos a los 49 años y con un perfil atípico. Pero hay rechazos que duelen especialmente.
Las API REST permiten a aplicaciones, servicios y capas de aplicación comunicarse entre sí, independientemente de las tecnologías subyacentes.
En las entregas anteriores hemos hablado del patrón Specification y cómo implementarlo en las diversas capas de arquitectura con la ayuda de Abstract Factory. Ahora toca ver cómo combinar Specification mediante el patrón Composite para construir especificaciones complejas a partir de otras más simples.
En esta entrega veremos como usar el patrón Abstract Factory para poder tener Specification adecuadas a diferentes capas e implementaciones.
El patrón specification es sumamente útil, pero implementarlo tiene su intríngulis. Este artículo tiene tres partes:
En los últimos días he estado trabajando ya en módulos específicos de la aplicación. En concreto la parte del CMS por ser la más visible y conceptualmente bastante sencilla. Así puedo hacer algunos experimentos interesantes en la separación de responsabilidades entre capas.
He aquí una estrategias sencilla para reescribir una clase legacy de manera ordenada, aplicando el principio de Inversión de Dependencia.
Cuando hablamos de Doctrine casi siempre pensamos en su ORM. Sin embargo, su capa de acceso a la base de datos es una gran herramienta poco conocida, de la que hay poca información aparte de la documentación oficial.
Database-first: al principio puede parecer fácil y hasta lógico. Es como el reverso tenebroso de la Fuerza, pero con datos.
Trabajar de forma individual hace que, a veces, descuides aspectos del flujo de trabajo que son cruciales en equipos. Uno de estos aspectos es la gestión de versiones y la ramificación de proyectos.
Como añadir autoload a un proyecto sin namespaces.
Este año 2017 tengo como objetivo conseguir un nuevo trabajo como desarrollador PHP y esto es lo que estoy aprendiendo.
Mientras el proceso de reescribir vistas avanza, vamos a darle vueltas a una cuestión importante.
A medida que la primera fase del proyecto avanza voy observando cosas en las que habrá que trabajar más a fondo.
Cuando analizas tu código antiguo es casi como analizar el código de otro desarrollador. En realidad es un poco peor, porque sabes que tú eres el responsable de esa masa de lodo. Esta es la tercera entrega de una serie sobre mi proyecto para abordar una aplicación legacy.
Esta es la segunda parte del relato del proceso que estoy siguiendo para reescribir una aplicación “legacy”.
Hace unos 15 años comencé a escribir mi primera aplicación seria en PHP. Esta aplicación fue creciendo y sufriendo diversos cambios y prestaciones. Ahora ha llegado el momento de replantearla.
El patrón visitante es uno de los que más difícil me ha resultado entender y aplicar, así que voy a escribir sobre él para afianzar el concepto.
El patrón Cadena de Responsabilidad (Chain of Responsibility) nos permite manejar una petición que puede ser atendida por varios objetos, sin saber a priori cual de ellos lo hará.
Los principios SOLID son cinco principios en el diseño orientado a objetos compilados por Robert C. Martin.
En Programación Orientada a Objetos el polimorfismo es una característica que nos permite enviar el mismo mensaje, desde el punto de vista sintáctico, a distintos objetos para que cada uno de ellos lo realice con un comportamiento específico.