TDD: esquema de selección de indicadores

Test Driven Development (TDD) no es solo una disciplina sobre la que nos encanta escribir, la practicamos todos los días. Esta es una publicación de blog que compartimos con amigos. Selva tropical de control de calidad. Como sabemos que no puede ser lo suficientemente bueno, lo publicamos aquí nuevamente. ¡Disfrutar!

librato-tdd

Librato es una rica tienda de ingeniería. Tenemos entre 40 y 60 implementaciones por día. De hecho, mientras escribo esto, hoy hemos implementado el código 40 veces, 12 de las cuales fueron cambios en producción (el resto se diseñó para diferentes entornos intermedios). Veo todas estas implementaciones en nuestro chat corporativo porque usamos chatbots para llevar el código a producción.

De hecho, gran parte de nuestra interacción con los servicios que componen las métricas de nuestros productos se abstrae de alguna manera detrás de los chatbots. Recibimos notificaciones de nuevos usuarios y problemas de producción de los chatbots, administramos nuestras funciones a través de los chatbots y quizás, obviamente, hemos integrado nuestras interacciones de Github y Travis-CI en el chat.

El resultado de todo esto es que cuando alguien fusiona algún código en un repositorio de producción, lo veo en un chat grupal:

descargar

Y no solo veo el cambio, sino que veo que el cambio ha pasado o fallado las pruebas unitarias:

descargar-1

Y no solo veo el resultado de la prueba, sino que incluso aquí hay un enlace a la salida de Travis para que pueda ver todo lo que hizo Travis. Lo siento si lo digo como si estuviera efusivamente; porque yo. Todavía me parece ciencia ficción, que con nuestro chatbot (twke por su nombre, literalmente llamado así por el ambiquad en Buck Rogers), que crea una instancia de un ordenador nueva para ejecutar cientos de pruebas automatizadas diseñadas para probar mi trabajo, antes de que se despliegue automáticamente en la internube. Pero digo esto como alguien que todavía piensa que MUD es bastante alegre. YMMV.

Índice

    ¿Cuántas pruebas hay?

    elegiré el nuestro servicio de alertaporque está escrito en Go y (ya que usa la plataforma de prueba Go integrada) es fácil de probar con grep.

    encontrar. | grep_test.go | inodoro -l

    Ofrece 44 archivos de prueba individuales. Aproximadamente uno en cada otro archivo con el sufijo .go en este repositorio, cada uno nombrado de acuerdo con el bloque que está probando. Así que para foo.go encontramos foo_test.go en aproximadamente la mitad del tiempo. Mirando ligeramente los archivos que no tienen un archivo de prueba relacionado, encontré principalmente definiciones de tipo y otro código relacionado con la estructura de datos (no el que normalmente verifica directamente).

    grep -ri 'Prueba de función. *' (prueba.T '. | wc -l

    Da 172 pruebas individuales. Relación de aproximadamente 4-1 de funciones comunes, para funciones de prueba.

    encontrar. | grep_test.go | al leer i; hacer egrep -v '({|})' $ {i} | grep'[a-z][A-Z]'; hecho | inodoro -l

    Me da alrededor de 2400 líneas de código dedicadas a las pruebas. De hecho, el código asociado con las pruebas es casi la mitad de este repositorio, medido por cadenas. Pues bien, revisamos mucho, pero hoy lo hacemos todos los que trabajamos en talleres de integración continua, realizando operaciones web/trabajos de ingeniería (¿no?).

    Si no practica la integración continua, estos números pueden parecerle excesivos. Pero entonces también me aventuraría a asumir que usted se ve obstaculizado por un proceso de gestión del cambio difícil y quizás políticamente cargado. Un proceso que probablemente implica una reunión semanal donde las personas que quieren implementar un código de producción proponen y defienden una propuesta de implementación en una sala poblada en su mayoría por otras personas que proponen y defienden sus propios cambios.

    Las reuniones de monitoreo de cambios están diseñadas para proteger un ambiente de trabajo saludable del error humano mediante la introducción de un nivel de revisión por pares. Si funciona o no es discutible, pero sin duda es lento y reduce el rendimiento. Los ciclos de producción largos dan más tiempo para el desarrollo y la producción de las industrias. Por lo tanto, la metodología clásica de control de cambios, al ralentizar el ciclo de lanzamiento, tiende a promover cambios más grandes y sustanciales (y, por lo tanto, más propensos a errores).

    La integración continua por comparación se basa en pruebas modulares para crear entornos de producción saludables a partir del error humano mediante la verificación directa de errores. Visto de esta manera, las pruebas son la base sobre la que se construye la integración continua. Podemos dedicar tanto tiempo a esto como lo que de otro modo dedicaríamos a detener el desempeño para crear propuestas de cambio y discutir sobre ellas en una reunión semanal. Cualquiera que tenga acceso a la corrección puede implementarla en producción con la frecuencia que desee, siempre que sus cambios pasen todas las pruebas modulares. Esto le permite realizar cambios más pequeños, más simples y más estables que son más fáciles de revertir en caso de un problema.

    Buenas pruebas nos ayudan a enviar

    descargar-2

    Por supuesto, nuestras pruebas no pueden proteger el entorno de producción si no tienen sentido. Al crearlos, debemos ser tanto procedimentales como electorales. Al igual que nuestro servicio de alerta, todo el código funcional debe organizarse en secciones, y cada sección debe tener una colección de pruebas que la acompañe. Pero tenemos que elegir los criterios de prueba que realmente nos ayudarán a enviar las mercancías de forma rápida y segura.

    Las buenas pruebas añaden contexto y fomentan la colaboración

    descargar-3

    Si hacemos nuestras pruebas demasiado difíciles, obsesivas o sin sentido, o si tratamos de imponer cosas como un estilo de codificación que no todos han aceptado aún, la gente simplemente las pasará por alto. La mayoría de las veces, cuando confiamos la creación de una prueba a un equipo en particular, es más probable que tal comportamiento fracase. Las pruebas básicamente deberían proporcionar los parámetros de rendimiento esperados de las cosas que creamos. Todo el mundo tiene que crearlos porque nos ayudan a todos a pensar en lo que esperamos de las cosas que construimos. Las pruebas que no hemos escrito deberían darnos una idea de las nuevas bases de código, no fomentar relaciones competitivas entre ingenieros.

    Buenas pruebas hacen buenas bases de código

    descargar-5

    Por lo tanto, crear y mantener buenas pruebas es tanto un arte como una ciencia. Esto requiere que reflexionemos sobre la "corrección" cuando diseñamos y construimos software, lo que nos obliga a conocer nuestras propias expectativas y suposiciones. Elegir buenas opciones de prueba significa una comprensión perfecta no solo de lo que creamos, sino también de la diferencia entre lo que creamos y lo que íbamos a crear en primer lugar. El código probado suele ser un código bien implementado, y el código mal implementado suele ser difícil de verificar.

    ¿Desarrollo orientado a indicadores?

    En este repositorio existe otra clase de código que no es funcional para la aplicación y no está relacionado con las pruebas modulares. El ejemplo se parece a esto:

    metrics.Measure ("outlet.poll.alerts.count", len (alertas))

    Este es el código de las herramientas, y grep tiene poco más de 200 líneas en este repositorio. La idea de los instrumentos es medir aspectos importantes de la aplicación desde adentro. Estas herramientas definen cosas como el tamaño de las colas, la cantidad de flujos de trabajo, los retrasos entre servicios y los tipos de consultas. Estas métricas luego se exportan a un sistema centralizado que nos ayuda a visualizar el funcionamiento interno de nuestras aplicaciones. A continuación, por ejemplo, se encuentra el tablero que usamos para monitorear el desempeño de nuestros servicios de alerta.

    descargar-6

    El buen rendimiento nos ayuda a enviar

    Las pruebas unitarias son como una señal de que necesitamos estar muy arriba antes de que podamos pasar a la producción. Nuestras figuras se parecen más a un canario en una mina de carbón. Estas son pruebas modulares que pueden seguir nuestro código en producción. Pueden probar constantemente nuestras suposiciones sobre los cambios que hacemos. Al igual que el desarrollo basado en pruebas, que usa pruebas modulares cuidadosamente pensadas para verificar la corrección, el desarrollo basado en métricas usa métricas seleccionadas deliberadamente para mostrarnos directamente el efecto de nuestros cambios.

    En Librato, consideramos tales figuras indispensables. Son el medio principal por el cual entendemos el comportamiento de nuestras aplicaciones en la naturaleza. Como resultado, seleccionamos cuidadosamente las métricas que rastreamos, y quizás no sea sorprendente que nuestras elecciones reflejen fundamentalmente nuestras elecciones de prueba.

    descargar-7

    Al igual que nuestras pruebas, nuestros indicadores no pueden proteger el entorno de producción si no tienen sentido. La integración continua en Librato depende en gran medida del buen rendimiento porque brinda una visibilidad fantástica; nos permiten observar cómo los cambios que introducimos afectan a las estructuras productivas.

    descargar-8

    Buen rendimiento hace buenas bases de código

    Hipótesis de sistemas de pruebas de buen desempeño. Confirman nuestras expectativas sobre cómo funcionan las cosas que construimos en la vida real. Al igual que las pruebas, todos deberían poder elegir y trabajar con sus propios indicadores porque nos ayudan a todos a pensar sobre lo que esperamos de las cosas que creamos. Las métricas pueden enseñarnos mucho sobre bases de código con las que no estamos familiarizados. Sin ninguna documentación, puedo sacar conclusiones sobre muchos de los indicadores anteriores, como que este servicio envía alertas, la cantidad de clientes que lo usan, las tasas de alertas generales e individuales, e incluso la estacionalidad del patrón de uso.

    descargar-9

    Por lo tanto, crear y mantener un buen desempeño es también un arte y una ciencia. Elegir métricas significativas requiere que pensemos en la "corrección" cuando desarrollamos y creamos software, pero si tenemos éxito, obtenemos una visión operativa constante que es invaluable para todos, ya sea que desarrollen sistemas, realicen pruebas de regresión, mantengan la infraestructura o entreguen funciones.

    Diseñar software con dispositivos es saludable. Nos permite conocer nuestras propias expectativas y suposiciones. El código bien medido suele ser un código bien implementado, y el código mal implementado suele ser difícil de medir. En Librato creemos que si crea pruebas modulares hoy, ya tiene las habilidades y la comprensión para seleccionar y combinar métricas en un flujo de telemetría en tiempo real poderoso con el que puede contar para mantener a sus clientes entusiasmados.

    Librato ofrece una prueba gratuita de 30 días y cuentas de desarrollador gratuitas con uso limitado. Regístrate hoy y agregue información a sus esfuerzos de ingeniería.

    Artículos de interés

    Subir