unit-testing - test - pruebas unitarias java

¿Cómo hacer que los programadores junior escriban pruebas? (24)

Tenemos un programador junior que simplemente no escribe suficientes pruebas.
Tengo que fastidiarlo cada dos horas, "¿has escrito pruebas?"
Lo hemos intentado:

Mostrando que el diseño se vuelve más simple
Mostrarlo previene defectos
Haciéndolo una cuestión de ego diciendo que solo los programadores malos no lo hacen
Este fin de semana 2 miembros del equipo tuvieron que venir a trabajar porque su código tenía una referencia NULL y no lo probó

Mi trabajo requiere un código estable de alta calidad, y generalmente todo el mundo lo entiende y no hay necesidad de pasar las pruebas. Sabemos que podemos hacerle escribir pruebas, pero todos sabemos que las pruebas útiles son aquellas escritas cuando te gusta.

¿Conoces más motivaciones?

Haga que la cobertura del código sea parte de las revisiones.
Haga que "escribir una prueba que expone el error" sea un requisito previo para corregir un error.
Requiere un cierto nivel de cobertura antes de que se pueda registrar el código.
Encuentre un buen libro sobre desarrollo basado en pruebas y úselo para mostrar cómo la prueba primero puede acelerar el desarrollo.

Él ya está haciendo esto. De Verdad. Él simplemente no lo escribe. ¿No convencido? Míralo pasar por el ciclo de desarrollo estándar:

Escribe un pedazo de código
Compilarlo
Ejecutar para ver lo que hace
Escribe la siguiente pieza de código

El paso # 3 es la prueba. Él ya hace pruebas, solo lo hace de forma manual. Hágale esta pregunta: "¿Cómo sabe mañana que el código de hoy todavía funciona?" Él responderá: "¡Es una cantidad tan pequeña de código!"

Pregunte: "¿Qué tal la próxima semana?"

Cuando no ha recibido una respuesta, pregunte: "¿Cómo le gustaría que su programa le diga cuándo un cambio rompe algo que funcionó ayer?"

De eso se trata la prueba automática de unidades.

@ jsmorris

Una vez hice que el desarrollador principal y el "arquitecto" me regañaran y probaran (era mi primer trabajo fuera de la universidad) en el correo electrónico por no quedarse hasta tarde y terminar una tarea "fácil" la noche anterior. Habíamos estado en ello todo el día y lo detuvimos a las 7 de la tarde, desde las 11 de la mañana antes del almuerzo había estado palpitando y había molestado a cada miembro de nuestro equipo por ayuda al menos dos veces.

Respondí y le dije al equipo: "Hace un mes que estoy decepcionado contigo. Nunca recibo ayuda del equipo. Si me necesitas, estaré en la cafetería del otro lado de la calle. lo siento, no pude depurar el parámetro 12, el método de 800 líneas del que todo depende. "

Después de refrescarme en la cafetería durante una hora, volví a la oficina, agarré mi porquería y me fui. Después de unos días me llamaron preguntando si iba a entrar, le dije que sí pero que tenía una entrevista, tal vez mañana.

"¿Así que estás renunciando entonces?"

Asignarlos a proyectos que no requieren "código estable de alta calidad" si esa es su preocupación y dejar que el jr. desarrollador falla Haz que sean ellos los que ''vengan el fin de semana'' para arreglar sus errores. Almuerce mucho y habla sobre prácticas de desarrollo de software (no conferencias, sino discusiones). Con el tiempo adquirirán y desarrollarán las mejores prácticas para realizar las tareas que se les asignan.

Quién sabe, incluso podrían llegar a algo mejor que las técnicas que su equipo utiliza actualmente.

Cambie la descripción de su trabajo durante un tiempo para que solo escriba pruebas y realice pruebas. He oído que muchas compañías hacen esto por nuevas personas inexpertas durante un tiempo cuando comienzan.

Además, emita un desafío mientras esté en esa función: escriba pruebas que a) fallen en el código actual a) cumplan con los requisitos del software. Afortunadamente, esto hará que cree pruebas sólidas y exhaustivas (mejorando el proyecto) y lo mejorará en las pruebas de escritura para cuando se reintegra en el desarrollo central.

edite> fulfull los requisitos del software, lo que significa que no solo está escribiendo pruebas para romper el código a propósito cuando el código nunca tuvo la intención o la necesidad de tener en cuenta ese caso de prueba.

Como programador junior, pensé que iba a revelar cómo era cuando me encontré en una situación similar a la de su desarrollador junior.

Cuando recién salí de la universidad, descubrí que no me había equipado para enfrentarme al mundo real. Sí, sabía algunos principios básicos de JAVA y algo de filosofía (no preguntes) pero eso fue todo. La primera vez que conseguí mi trabajo fue un poco desalentador por decir lo menos. Déjame que te diga que probablemente sea uno de los vaqueros más grandes, me gustaría armar un pequeño algoritmo / solución de errores sin comentarios / pruebas / documentación y enviarlo a la puerta.

Tuve la suerte de estar bajo la supervisión de un amable y muy paciente programador senior. Afortunadamente para mí, decidió sentarse conmigo y pasar 1-2 semanas revisando mi código de togethor muy pirateado. Él me explicaba dónde me había equivocado, los puntos más finos de C y los punteros (¡eso me confundió a mí!). Nos las arreglamos para escribir una clase / módulo bastante decente en aproximadamente una semana. Todo lo que puedo decir es que si el desarrollador senior no hubiera invertido el tiempo para ayudarme en el camino correcto, probablemente no habría durado mucho.

Afortunadamente, 2 años después, espero que algunos de mis colegas incluso me consideren un programador promedio.

Llevese a casa puntos

La mayoría de las universidades son muy malas preparando estudiantes para el mundo real
La programación sincronizada realmente me ayudó. Eso no quiere decir que ayudará a todos, pero funcionó para mí.

Como programador junior, todavía estoy tratando de adquirir el hábito de escribir pruebas. Obviamente, no es fácil aprender nuevos hábitos, pero pensando en lo que haría que esto funcione para mí, tengo que hacer +1 en los comentarios sobre las revisiones de códigos y la programación de coaching / pair.

También puede valer la pena enfatizar el propósito a largo plazo de las pruebas: garantizar que lo que funcionó ayer siga funcionando hoy y la semana que viene y el mes que viene. Solo digo eso porque al analizar las respuestas no vi eso mencionado.

Al hacer revisiones de código (si decides hacerlo), asegúrate de que tu joven desarrollador sepa que no se trata de menospreciarlo, sino de mejorar el código. Porque de esa manera es menos probable que su confianza se dañe. Y eso es importante Por otro lado, también lo es saber lo poco que sabes.

Por supuesto, realmente no sé nada. Pero espero que las palabras hayan sido útiles.

Editar: [ ]
No te desanimes, lo que tienes que decir está más o menos en lo cierto.
En su punto sobre las revisiones de código: lo que encontrará es que no solo el desarrollador junior aprenderá en el proceso, sino también los revisores. Todos en una revisión de código aprenden si lo conviertes en un proceso colaborativo.

En base a su comentario, "Mostrando que el diseño se vuelve más simple", asumo que ustedes practican TDD. Hacer una revisión del código después del hecho no va a funcionar. Todo sobre TDD es que es una filosofía de diseño y no de prueba. Si no escribió las pruebas como parte del diseño, no obtendrá muchos beneficios de escribir pruebas después del hecho, especialmente de un desarrollador junior. Terminará perdiendo muchos casos de esquina y su código seguirá siendo malo.

Su mejor opción es tener un desarrollador senior muy paciente para sentarse con él y hacer un par de programación. Y solo sigue así hasta que aprenda. O no aprende, en cuyo caso necesita reasignarlo a una tarea que le conviene más porque terminará frustrando a sus desarrolladores reales.

No todos tienen el mismo nivel de talento y / o motivación. Los equipos de desarrollo, incluso los ágiles, están formados por personas del "Equipo A" y personas del "Equipo B". Los miembros de A-Team son los que diseñan la solución, escriben todos los códigos de producción no triviales y se comunican con los propietarios de las empresas, todo el trabajo que requiere pensar de manera innovadora. El equipo B maneja cosas como administración de configuración, escritura de guiones, reparación de errores cojos y realización de trabajos de mantenimiento, todo el trabajo que tiene procedimientos estrictos que tienen pequeñas consecuencias para el fracaso.

En primer lugar, como la mayoría de los encuestados aquí señalan, si el hombre no ve el valor de las pruebas, no hay mucho que pueda hacer al respecto, y ya ha señalado que no puede despedir al tipo. Sin embargo, la falla no es una opción aquí, ¿qué hay de las pocas cosas que puedes hacer?

Si su organización es lo suficientemente grande como para tener más de 6 desarrolladores, le recomiendo tener un departamento de Garantía de calidad (aunque sea una sola persona para comenzar). Idealmente, debe tener una proporción de 1 probador a 3-5 desarrolladores. Lo que pasa con los programadores es ... son programadores, no probadores. Todavía tengo que entrevistar a un programador al que se le han enseñado formalmente técnicas de control de calidad adecuadas.

La mayoría de las organizaciones cometen el error fatal de asignar los roles de prueba a la nueva contratación, la persona con la menor cantidad de exposición a su código: idealmente, los desarrolladores sénior deben pasar al rol de QA ya que tienen la experiencia en el código , y (con suerte) han desarrollado un sexto sentido para olores de código y puntos de falla que pueden surgir.

Además, el programador que cometió el error probablemente no encontrará el defecto porque generalmente no es un error de sintaxis (los recogen en la compilación), sino un error de lógica, y la misma lógica funciona cuando escriben el prueba como cuando escriben el código. No haga que la persona que desarrolló el código pruebe ese código; encontrará menos errores que los demás.

En su caso, si puede permitirse el esfuerzo de trabajo redirigido, conviértalo en el primer miembro de su equipo de control de calidad. Haga que lea "Pruebas de software en el mundo real: Mejorando el proceso", porque obviamente necesitará capacitación en su nuevo rol. Si no le gusta, se rendirá y su problema aún está resuelto.

Un enfoque un poco menos vengativo sería dejar a esta persona hacer lo que es bueno (supongo que esta persona fue contratada porque es realmente competente en la parte de programación del trabajo), y contratar uno o dos probadores para hacer las pruebas ( Los estudiantes universitarios a menudo tienen términos prácticos o de "cooperación", les encantaría la exposición y son baratos.

Nota al margen: Eventualmente, querrá que el equipo de control de calidad informe a un director de control de calidad, o al menos no a un administrador de desarrollador de software, porque hacer que el equipo de control de calidad informe al gerente quién es el principal objetivo para realizar el producto es un conflicto de interesar.

Si su organización es menor de 6, o no puede salirse con la suya creando un nuevo equipo, recomiendo la programación por pares (PP). No soy un converso total de todas las técnicas de programación extremas, pero definitivamente creo en la programación de pares. Sin embargo, ambos miembros del equipo de programación emparejado deben ser dedicados o simplemente no funcionan. Deben seguir dos reglas: el inspector debe comprender completamente lo que se codifica en la pantalla o debe pedirle al codificador que lo explique; el codificador solo puede codificar lo que puede explicar: no se tolerarán "verá" o "confíe en mí" ni agitará la mano.

Solo recomiendo PP si su equipo es capaz de hacerlo, porque, como las pruebas, ninguna cantidad de vítores o amenazas convencerán a un par de introvertidos llenos de ego para que trabajen juntos si no se sienten cómodos haciéndolo. Sin embargo, me parece que entre la elección de escribir especificaciones funcionales detalladas y hacer revisiones de código frente a la programación combinada, el PP suele ganar.

Si PP no es para ti, entonces TDD es tu mejor opción, pero solo si se toma literalmente. El desarrollo impulsado por prueba significa que primero se escriben las pruebas, se ejecutan las pruebas para demostrar que realmente fallan y luego se escribe el código más simple para que funcione. La compensación ahora es que (debería) tener una colección de miles de pruebas, que también es código, y es tan probable como el código de producción para contener errores. Seré sincero, no soy un gran admirador de TDD, principalmente por esta razón, pero funciona para muchos desarrolladores que prefieren escribir scripts de prueba en vez de documentos de casos de prueba: algunas pruebas son mejores que ninguna. Par TDD con PP para una mejor probabilidad de cobertura de prueba y menos errores en el script.

Si todo lo demás falla, haga que los programadores equivalen a un jarrón: cada vez que el programador rompe la compilación, tienen que poner $ 20, $ 50, $ 100 (lo que sea moderadamente doloroso para su personal) en un frasco que vaya a su favorito ( registrado!) caridad. Hasta que paguen, evítelos :)

Bromas aparte, la mejor manera de hacer que tu programador escriba pruebas es no dejarlo programar. Si quieres un programador, contrata a un programador. Si quieres pruebas, contrata un probador. Empecé como programador junior hace 12 años haciendo pruebas, y se convirtió en mi camino profesional, y no lo cambiaría por nada. Un departamento de control de calidad sólido que se nutre adecuadamente y se le da el poder y el mandato para mejorar el software es tan valioso como los desarrolladores que escriben el software en primer lugar.

En su repositorio de origen: use los enlaces antes de cada commit (enlace de precompilación para SVN, por ejemplo)

En ese gancho, verifique la existencia de al menos un caso de uso para cada método. Use una convención para la organización de pruebas unitarias que pueda aplicar fácilmente a través de un enlace de precompromiso.

En un servidor de integración compila todo y verifica regularmente la cobertura de prueba con una herramienta de cobertura de prueba. Si la cobertura de la prueba no es del 100% para un código, bloquea cualquier compromiso del desarrollador. Él debería enviarle el caso de prueba que cubre el 100% del código.

Solo los controles automáticos pueden escalar bien en un proyecto. No puedes verificar todo a mano.

El desarrollador debe tener un medio para verificar si sus casos de prueba cubren el 100% del código. De esa forma, si no comete un código 100% probado, es su propia culpa, no una falla de "Uy, lo siento, olvidé".

Recuerde: las personas nunca hacen lo que espera, siempre hacen lo que inspeccionan.

Es su Mentor la responsabilidad de enseñarle a él / ella. ¿Qué tan bien le estás enseñando CÓMO poner a prueba? ¿Estás emparejando la programación con él? Lo más probable es que el Junior no sepa CÓMO establecer una buena prueba para xyz.

Como joven recién salida de la escuela, conoce muchos Conceptos. Alguna técnica Alguna experiencia. Pero al final, todo un Junior es POTENCIAL. Casi todas las funciones en las que trabajan, habrá algo nuevo que nunca antes hayan hecho. Seguramente el Junior puede haber hecho un patrón de estado simple para un proyecto en clase, abriendo y cerrando "puertas", pero nunca una aplicación de los patrones en el mundo real.

Él / ella solo será tan bueno como tan bien enseñe. Si fueran capaces de "solo obtenerlo", ¿creen que habrían tomado una posición Junior en primer lugar?

En mi experiencia, los jóvenes son contratados y se les da casi la misma responsabilidad que a las personas mayores, pero se les paga menos y luego se les ignora cuando empiezan a fallar. Perdóname si parezco amargado, es porque soy.

Esta es una de las cosas más difíciles de hacer. Lograr que su gente lo obtenga

A veces, una de las mejores maneras de ayudar a los programadores de nivel junior a ''obtenerlo'' y aprender las técnicas correctas de las personas mayores es hacer un poco de programación de pares.

Pruebe esto: en un próximo proyecto, empareje al chico junior con usted u otro programador senior. Deben trabajar juntos, turnándose para "conducir" (ser el que está escribiendo en el teclado) y "entrenar" (mirar por encima del hombro del conductor y señalar sugerencias, errores, etc. a medida que avanzan). Puede parecer una pérdida de recursos, pero encontrará:

Que estos muchachos juntos pueden producir código rápidamente y de mayor calidad.
Si su chico junior aprende lo suficiente como para "conseguirlo" con un chico mayor que lo dirige por el camino correcto (por ejemplo, "Ok, ahora antes de continuar, vamos a escribir para la prueba de esta función"). Valdrá la pena los recursos que comprometerse con eso

Tal vez también alguien en su grupo haya dado la presentación de Unit Testing 101 por Kate Rhodes, y creo que es una gran manera de entusiasmar a la gente con las pruebas, si se realiza bien.

Otra cosa que puedes hacer es que tus Jr. Devs practiquen el juego de bolos Kata, que les ayudará a aprender el desarrollo impulsado por pruebas. Está en Java, pero podría adaptarse fácilmente a cualquier idioma.

Esto es lo que haría:

Por primera vez ... "vamos a hacer este proyecto conjuntamente. Voy a escribir las pruebas y vas a escribir el código. Presta atención a cómo escribo las pruebas, porque así es como hacemos las cosas por aquí y eso es lo que esperaré de ti ".
Después de eso ... "¡Ya terminaste! ¡Genial! Primero veamos las pruebas que están impulsando tu desarrollo. Oh, no hay pruebas. Avísame cuando se haga eso y volveremos a programar la revisión de tu código. Re necesita ayuda para formular las pruebas, házmelo saber y te ayudaré ".

Esto puede ser un poco desalmado, pero la forma en que describes la situación parece que necesitas despedir a este tipo. O al menos aclararlo: negarse a seguir las prácticas de desarrollo de la casa (incluidas las pruebas de escritura) y verificar el código de error que otras personas deben limpiar eventualmente lo despedirá.

Francamente, si tiene que esforzarse tanto para lograr que haga algo, entonces deberá llegar a un acuerdo con la idea de que tal vez no sea una buena opción para el equipo y que deba irse. Ahora, esto no necesariamente significa despedirlo ... puede significar encontrar otro lugar en la compañía en el que sus habilidades sean más adecuadas. Pero si no hay otro lugar ... ya sabes qué hacer.

Supongo que también es un empleado relativamente nuevo (<1 año) y probablemente recién salido de la escuela ... en cuyo caso puede que no esté acostumbrado a cómo funcionan las cosas en un entorno corporativo. Cosas como esas que la mayoría de nosotros podríamos hacer en la universidad.

Si este es el caso, una de las cosas que he encontrado que funciona es tener una especie de "nueva contratación sorpresa". No importa si nunca lo has hecho antes ... él no lo sabrá. Solo siéntalo y dile que vas a repasar su actuación y muéstrale algunos números reales ... toma tu hoja de revisión normal (¿tienes un proceso de revisión formal, correcto?) Y cambia el encabezado si quieres para que se vea oficial y mostrarle dónde se encuentra. Si le muestras en un entorno muy formal que no hacer las pruebas está afectando negativamente a su calificación de rendimiento en lugar de simplemente "molestarlo" por ello, con suerte obtendrá el punto. Tienes que demostrarle que sus acciones realmente lo afectarán, ya sea pagando o no.

Lo sé, es posible que desee mantenerse alejado de hacer esto porque no es oficial ... pero creo que está dentro de lo razonable para hacerlo y probablemente sea mucho más barato que tener que despedirlo y contratar a alguien nuevo.

Haga una revisión del código antes de cada confirmación (incluso si es un minuto "He cambiado el nombre de esta variable"), y como parte de la revisión del código, revise las pruebas de cada unidad.

No firme la confirmación hasta que las pruebas estén en su lugar.

(Además, si su trabajo no fue probado, ¿por qué estaba en una producción de construcción en primer lugar? Si no está probado, no lo deje entrar, entonces no tendrá que trabajar los fines de semana)

Imagina que soy un programador simulado, llamado ... Marco. Imagínense que me gradué de la escuela no hace mucho, y nunca tuve que escribir pruebas. Imagina que trabajo en una empresa que realmente no hace cumplir o solicita esto. ¿OKAY? ¡bueno! Ahora imagine, que la compañía está cambiando a usar pruebas, y están tratando de ponerme en línea con esto. Daré una reacción un tanto sarcástica a los artículos mencionados hasta ahora, como si no hubiera investigado sobre esto.

Comencemos con el creador:

Mostrando que el diseño se vuelve más simple.

¿Cómo se puede escribir más, hacer las cosas más simples? Ahora tendría que vigilar para obtener más casos, etc. Esto lo hace más complicado si me preguntas. Dame detalles sólidos.

Mostrarlo evita defectos.

Yo sé eso. Es por eso que se llaman pruebas. Mi código es bueno y lo revisé en busca de problemas, por lo que no veo dónde podrían ayudar esas pruebas.

Convertirlo en algo del ego diciendo que solo los programadores malos no lo hacen.

Ohh, entonces piensas que soy un mal programador solo porque no hago tantas pruebas usadas. Estoy insultado y positivamente molesto contigo. Prefiero tener ayuda y apoyo que refranes.

@ Justin Standard : en el inicio del nuevo par de pronósticos, el chico más joven se pondrá contigo o con otro programador senior.

Ohh, esto es tan importante que los recursos se gastarán asegurándome de ver cómo se hacen las cosas, y que me ayuden en cómo se hacen las cosas. Esto es útil, y podría comenzar a hacerlo más.

@ Justin Standard : presentación de Read Unit Testing 101 por Kate Rhodes.

Ahh, esa fue una presentación interesante, y me hizo pensar en las pruebas. Abundó algunos puntos que debería considerar, y podría haber influido un poco en mis puntos de vista.

Me encantaría ver artículos más convincentes y otras herramientas para ayudarme a estar en línea con el pensamiento de que esta es la manera correcta de hacer las cosas.

@ Dominic Cooney : dedique algo de tiempo y comparta técnicas de prueba.

Ahh, esto me ayuda a entender lo que se espera de mí en cuanto a técnicas, y pone más elementos en mi bolsa de conocimiento, que podría usar nuevamente.

@ Dominic Cooney : Responda preguntas, ejemplos y libros.

Tener una persona de punto (personas) para responder la pregunta es útil, podría hacer que sea más probable que lo intente. Los buenos ejemplos son geniales, y me da algo para apuntar, y algo para buscar referencia. Los libros que son relevantes para esto directamente son una gran referencia.

@ Adam Hayle : Surprise Review.

Dime qué, saltaste algo para lo que no estoy preparado. Me siento incómodo con esto, pero haré lo mejor que pueda. Ahora estaré asustado y un poco aprensivo de que esto vuelva a suceder, gracias. Sin embargo, la táctica de miedo podría haber funcionado, pero tiene un costo. Sin embargo, si nada funciona, esto podría ser el impulso que se necesita.

@ Rytmis : los artículos solo se consideran hechos cuando tienen casos de prueba.

Ohh, interesante. Veo que realmente tengo que hacer esto ahora, de lo contrario, no estoy completando nada. Esto tiene sentido.

@ jmorris : Get Rid / Sacrifice.

miradas, miradas, miradas : existe la posibilidad de que aprenda, y con apoyo y asistencia, puedo convertirme en una parte muy importante y funcional de los equipos. Esta es una de mis desventajas ahora, pero no será por mucho tiempo. Sin embargo, si simplemente no lo entiendo, entiendo que iré. Creo que lo conseguiré

Al final, el apoyo de mi equipo juega un papel importante en todo esto. Hacer que una persona se tome su tiempo para ayudar y que me inicie en buenos hábitos siempre es bienvenido. Entonces, tener una buena red de apoyo sería genial. Siempre se agradecerá que alguien venga varias veces después y revise algún código para ver cómo fluye todo, no en una revisión per se, sino más bien como una visita amistosa.

Razonamiento, preparación, enseñanza, seguimiento, apoyo.

La razón principal por la cual los ingenieros / programadores menores no toman mucho tiempo para diseñar y ejecutar scripts de prueba, es porque la mayoría de las certificaciones de CS no requieren esto, por lo que otras áreas de ingeniería se cubren más en los programas universitarios, como los patrones de diseño.

En mi experiencia, la mejor manera de incorporar a los profesionales jóvenes al hábito es hacer que forme parte del proceso explícitamente. Es decir, al estimar el tiempo que debe tomar una iteración, el tiempo de diseño, escritura y / o ejecución de los casos debe incorporarse en esta estimación de tiempo.

Por último, revisar el diseño del script de prueba debe ser parte de una revisión del diseño, y el código real debe revisarse en la revisión del código. Esto hace que el programador sea responsable de hacer las pruebas adecuadas de cada línea de código que escribe, y del ingeniero superior y sus compañeros que puedan proporcionar comentarios y orientación sobre el código y la prueba escrita.

Me he dado cuenta de que muchos programadores ven el valor de las pruebas en un nivel racional. Si has escuchado cosas como "sí, sé que debería probar esto, pero realmente necesito terminar esto rápidamente", entonces ya sabes a qué me refiero. Sin embargo, a nivel emocional, sienten que hacen algo solo cuando escriben el código real.

El objetivo, entonces, debería ser lograr que comprendan que las pruebas son, de hecho, la única forma de medir cuándo algo está "hecho" y, por lo tanto, darles la motivación intrínseca para escribir las pruebas.

Aunque me temo que es mucho más difícil de lo que debería ser. Escuchará muchas excusas como "Tengo mucha prisa, lo reescribiré / refactorizaré más tarde y luego añadiré las pruebas", y por supuesto, el seguimiento nunca ocurre porque, sorprendentemente, Está tan ocupado la próxima semana .

Mucha psicología y técnicas útiles de "tutoría", pero sinceramente, esto simplemente se reduce a "escribir pruebas si aún quieres tener un trabajo, mañana".

Puedes jugarlo en los términos que consideres apropiados, duros o suaves, no importa. Pero el hecho es que a los programadores no se les paga para simplemente juntar el código y registrarlo, sino que les pagan para armar cuidadosamente el código, luego preparan pruebas, luego prueban su código, LUEGO revisan todo. (Al menos así es como suena, según tu descripción).

Por lo tanto, si alguien se niega a hacer su trabajo, explíqueles que pueden quedarse en casa, mañana, y contratará a alguien que HAGA el trabajo.

De nuevo, puedes hacer todo esto con cuidado, si crees que es necesario, pero mucha gente solo necesita una gran cachetada de Life In The Real World , y les harías un favor dándoselo.

Buena suerte.

Para mí, he empezado a insistir en que cada error que encuentre y solucione se exprese como una prueba:

"Hmmm, eso no está bien ..."
Encuentra un posible problema
Escriba una prueba, demuestre que el código falla
Arreglar el problema
Mostrar que el nuevo código pasa
Bucle si el problema original persiste

Trato de hacer esto incluso mientras hago ruido, y termino casi al mismo tiempo, solo con un conjunto de prueba parcial ya en su lugar.

(No vivo en un entorno de programación comercial, y a menudo soy el único programador que trabaja en un proyecto en particular).

Secundo el comentario de RodeoClown sobre el código revisando cada confirmación. Una vez que lo haya hecho varias veces, tendrá el hábito de probar cosas.

No obstante, no sé si necesitas bloquear commits así. En mi lugar de trabajo, todos tienen compromiso libre para todo, y todos los mensajes de compromiso de SVN (con diffs) se envían por correo electrónico al equipo.

Nota: realmente desea el complemento thunderbird colored-diffs si planea hacerlo.

Mi jefe o yo mismo (los 2 codificadores "senior") terminaremos leyendo sobre los commits, y si hay cosas como "se olvidó de agregar pruebas unitarias", simplemente seleccionamos un correo electrónico o vamos a hablar con la persona, explicando por qué pruebas unitarias necesarias o lo que sea. A todos los demás se les anima a leer los commits también, ya que es una gran forma de ver lo que está sucediendo, pero los desarrolladores más jóvenes no comentan tanto.

Puedes ayudar a alentar a la gente a acostumbrarse a esto diciendo periódicamente cosas como "Oye, bob, ¿viste esa promesa que hice esta mañana, encontré este truco ordenado en el que puedes hacer bla bla bla, leer el compromiso y ver ¡cómo funciona!"

NB: Tenemos 2 desarrolladores ''senior'' y 3 juniors. Puede que no se escale, o puede que necesite ajustar el proceso un poco con más desarrolladores.

Si a su colega le falta experiencia en escribir pruebas, tal vez tenga dificultades para realizar la prueba más allá de situaciones simples, y eso se manifiesta como una prueba inadecuada. Esto es lo que probaría:

Dedique algo de tiempo y comparta técnicas de prueba, como inyección de dependencia, buscando casos límite, y así sucesivamente con su colega.
Ofrezca responder preguntas sobre pruebas.
Haga revisiones de los códigos por un tiempo. Pídale a su colega que revise los cambios que haya realizado y que sean ejemplares de buenas pruebas. Mire sus comentarios para ver si realmente están leyendo y entendiendo su código de prueba.
Si hay libros que encajan particularmente bien con la filosofía de evaluación de su equipo, dele una copia. Podría ser útil si el código revisa los comentarios o las discusiones que hacen referencia al libro, de modo que él o ella tengan un hilo para recoger y seguir.

No enfatizaría especialmente el factor de vergüenza / culpabilidad. Vale la pena señalar que las pruebas son una buena práctica ampliamente adoptada y que escribir y mantener buenas pruebas es una cortesía profesional, por lo que los compañeros de equipo no necesitan pasar los fines de semana en el trabajo, pero yo no aclararía esos puntos.

Si realmente necesitas "ponerte fuerte", instituye un sistema imparcial; A nadie le gusta sentir que los están discriminando. Por ejemplo, es posible que su equipo requiera un código para mantener un cierto nivel de cobertura de prueba (puede ser evaluado, pero al menos puede ser automatizado); requiere un nuevo código para tener pruebas; requerir que los revisores consideren la calidad de las pruebas al hacer revisiones de código; y así. La institución de ese sistema debería provenir del consenso del equipo. Si modera la discusión con cuidado, puede descubrir otras razones subyacentes por las que las pruebas de su colega no son las esperadas.

Si el programador junior, o cualquiera, no ve el valor en las pruebas, entonces será difícil lograr que lo hagan ... punto.

Habría hecho que el programador junior sacrificara su fin de semana para arreglar el error. Sus acciones (o la falta de ellas) no lo afectan directamente. Además, deje en claro que no verá avances y / o aumentos salariales si no mejora sus habilidades en las pruebas.

Al final, incluso con toda su ayuda, estímulo, tutoría, puede que no sea apto para su equipo, así que déjelo ir y buscar a alguien que sí lo tenga.