Pruebas de unidad e integración: ¿cómo puede convertirse en un reflejo?

Todos los programadores de mi equipo están familiarizados con las pruebas unitarias y las pruebas de integración. Todos hemos trabajado con eso. Tenemos todas las pruebas escritas con él. Algunos de nosotros incluso hemos sentido una mayor sensación de confianza en su propio código.

Sin embargo, por alguna razón, escribir pruebas de unidad / integración no se ha convertido en un reflejo para ninguno de los miembros del equipo. Ninguno de nosotros se siente mal cuando no escribimos pruebas unitarias al mismo tiempo que el código real. Como resultado, nuestra base de código se descubre principalmente mediante pruebas unitarias, y los proyectos entran en producción sin probar.

El problema con eso, por supuesto, es que una vez que sus proyectos están en producción y ya funcionan bien, es prácticamente imposible obtener tiempo y / o presupuesto para agregar pruebas de unidad / integración.

Los miembros de mi equipo y yo ya estamos familiarizados con el valor de las pruebas unitarias ( 1 , 2 ), pero no parece ayudar a incorporar las pruebas unitarias a nuestro flujo de trabajo natural. En mi experiencia, hacer que las pruebas unitarias y / o una cobertura objetivo sean obligatorias solo da como resultado pruebas de baja calidad y ralentiza a los miembros del equipo simplemente porque no existe una motivación autogenerada para producir estas pruebas. Además, tan pronto como la presión disminuye, las pruebas unitarias ya no se escriben.

Mi pregunta es la siguiente: ¿Hay algún método con el que hayas experimentado que ayude a construir una dinámica / impulso dentro del equipo, lo que lleva a las personas que naturalmente desean crear y mantener esas pruebas?

Ninguno de nosotros se siente mal cuando no escribimos pruebas unitarias al mismo tiempo que el código real.

Este es el punto que debe abordar. La cultura de su equipo debe cambiar de modo que no escribir pruebas durante el sprint (o cualquier unidad de tiempo que use) se convierta en un olor de código tanto como los valores de codificación rígida. Gran parte de eso implica la presión de grupo. Nadie realmente quiere ser visto como deficiente.

Haz las pruebas tú mismo. Se regaña visiblemente cuando no los haces. Señale dónde un programador "bueno" habría detectado ese error si hubiera escrito pruebas unitarias. Nadie quiere ser malo. Haz que este comportamiento indeseable sea malo y que la gente lo siga.

Lograr que todo un equipo realmente quiera lo mismo puede ser bastante difícil. A menudo ocurre que ver el valor de algo no es suficiente en sí mismo para alentar a las personas a cambiar su comportamiento arraigado. Incluso aquellos que valoran el cambio y que lo quieren específicamente a veces también pueden ser responsables de combatirlo inconscientemente.

El problema es realmente una motivación individual y no una motivación de equipo como tal. Llega un momento en que te llega un momento de claridad, ya sea como resultado de algo que finalmente entendiste, o debido a alguna herramienta nueva u otra cosa subjetiva que hace que el programador promedio arroje todo y cambie por completo el proceso. Su trabajo, en caso de que elija exceptuarlo, es ver si hay una manera para que usted o el equipo descubran qué cosas serán los desencadenantes de la claridad para cada miembro individual del equipo.

Para mí personalmente, fue simplemente descubrir el marco StoryQ para BDD en DotNet, lo que hizo que fuera muy fácil ignorarlo y me superó por completo la "barrera" de prueba primero versus prueba simultánea. Más tarde tuve mis elecciones reafirmadas cuando encontré NCrunch para Visual Studio. La mitad de la batalla a veces no es vender la idea, sino simplemente reducir el esfuerzo requerido para introducir un cambio radical en los hábitos ... e incluso entonces puede tomar un poco de tiempo y trabajo. Sin embargo, estos mismos desencadenantes personales no fueron suficientes para influir en el enfoque de mis colegas en ese momento, que todavía escriben la mayor parte de su código de prueba simultáneamente o incluso después de su código de implementación.

A veces, también, hay renuencia a cambiar la forma en que se hacen las cosas, debido a un miedo inherente, desconfianza o visión desagradable del esfuerzo requerido para aprender a hacer algo de manera diferente, incluso cuando el razonamiento para el cambio es sólido. Si toda su plataforma de prueba está diseñada para funcionar de una manera específica, puede ser difícil justificar el cambio en la forma en que se hacen las cosas y potencialmente cambiar las herramientas , especialmente cuando las pruebas viejas y nuevas deberán continuar coexistiendo durante toda la vida útil de la prueba. proyecto, y ciertamente no querrás tener que volver a escribir cada prueba que hayas creado. Lo extraño es que a veces las personas sienten que esta es la única forma de adoptar una nueva metodología de prueba, y eso en sí mismo dificulta que esas personas acepten un cambio sensible para mejor.

Realmente, la única forma en que algo se vuelve reflexivo es forzándose a hacerlo una y otra vez hasta que ya no note que necesita concentrarse demasiado en cómo hacerlo. A veces, la única forma de hacer esto en un equipo es establecer políticas que puedan parecer un poco draconianas, y practicar la programación de pares y las revisiones de código, y cualquier otra cosa que pueda ayudar a los miembros del equipo a respaldarse y literalmente forzar el cambio en comportamiento a ocurrir. Sin embargo, para que dicha estrategia sea realmente exitosa, aún requiere un compromiso firme y honesto de todos y cada uno de los miembros del equipo para aceptar las medidas necesarias y participar en el proceso ... y mucha paciencia de todos los involucrados .

Ninguno de nosotros se siente mal cuando no escribimos pruebas unitarias al mismo tiempo que el código real

No estoy seguro de lo que quieres decir con "al mismo tiempo", pero ¿qué tal si los escribes antes del código real?

Es fácilmente comprensible desde una perspectiva psicológica por qué cualquier ser humano no querría molestarse en escribir pruebas unitarias después del código. En ese punto, el código ya está funcionando, entonces, ¿por qué deberíamos probarlo? Algún tipo de pereza ocurre automáticamente porque es tedioso, aparentemente inútil y no escribir pruebas no parece ser peligroso. Como resultado, no conozco muchos equipos que siguieron con un enfoque de prueba después de un largo período de tiempo.

Sin embargo, en mi experiencia, probar primero (estilo TDD) es algo a lo que se puede volver adicto rápidamente porque tiene al menos 2 beneficios inmediatos, tangibles y liberadores de endorfinas:

• Le ayuda a diseñar su código cara a cara con requisitos ejecutables concretos y a mejorar el diseño a medida que refactoriza, lo que es mucho más útil y gratificante que simplemente verificar dos veces algo que ya funciona.

• El ciclo TDD está marcado por momentos frecuentes de "barra verde" donde puede disfrutar el sabor del éxito inmediato. Constantemente mantiene su mente satisfecha y lista para usar la siguiente característica a implementar.

Así que no intentaría hacer que su equipo se sintiera mal cuando no escribieran las pruebas. En cambio, trataría de hacerlos sentir bien como lo hacen. TDD es una forma de hacer esto.

primero deberá asegurarse de que escribir una prueba y ejecutarla sea fácil, configurar el marco en los proyectos actuales y hacer que el procedimiento de configuración sea fácil de incluir en proyectos futuros

de esta forma, cuando un programador quiere probar una nueva característica que está tratando de depurar, no tiene que saltar una docena de aros para que las pruebas funcionen correctamente

cuanto más incómodo es hacer menos es menos probable que se convierta en un hábito

Una cosa que he hecho que ha tenido éxito en instigar un cambio de cultura es organizar un seminario semanal de "curación de pruebas unitarias". El propósito oficial de esto es ayudar a mantener el conjunto de pruebas de la unidad funcionando rápidamente y actualizado, pero el propósito más importante, en mi opinión, es dar a las personas una forma de baja presión para entrar, hacer preguntas y practicar pruebas . El hecho de que esté dispuesto a pasar una hora o lo que sea por semana exclusivamente en las pruebas también envía el mensaje de que esto es importante.

Creo que de esta manera obtienes un poco de cambio cultural y comienzas a eliminar la barrera para hacerlo "reflexivamente", como lo expresas. La gente tenderá a volver a los viejos hábitos a la primera señal de adversidad: tener una reunión como esta no solucionará eso de una sola vez, pero creo que iniciará un cambio cultural y eliminará la barrera que resulta de no realmente sabiendo lo que estás haciendo.

Tener un grupo de programadores en el que todos naturalmente quieran hacer algo es una utopía (especialmente cuando se habla de un grupo grande).

Las pruebas de unidad e integración son cosa de estándares . Usted crea un estándar para un flujo de trabajo y cada miembro del equipo debe respetarlo. Los estándares deben hacerse con la ayuda de profesionales de control de calidad, porque ellos lo conocen mejor. Un programador debe respetar los estándares. Lo que puede hacer es hacer que los estándares sean limpios, fáciles de entender y seguir.

No se trata de confiar en su propio código y de los deseos de usar, se trata de necesitar tener estándares de codificación y prueba que todos usen para hacer cosas buenas, y cualquier programador debe entender esto.

Cuando haces que las personas desde el principio sigan el estándar, se convierte en un reflejo y se seguirá. Hacer que sea una regla que no se pueda poner código en la base de código sin una prueba unitaria convencería a las personas de que tienen que hacerlo. Para los repositorios de proyectos hay reglas aún más restrictivas. Por ejemplo, las compañías hacen pruebas unitarias antes de codificar realmente la unidad (cuando hacen la especificación del módulo) y este es un método muy bueno. Si un programador coloca código en el proyecto / base de código, el código se ejecuta a través del módulo de prueba y si las pruebas unitarias no pasan, vuelven a funcionar.

Si en este momento es difícil agregar estándares y reglas, al menos piense en agregarlos en proyectos futuros.