¿Cómo hacer que los programadores junior escriban pruebas? [cerrado]

Tener una revisión de 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 de código, revisar cualquier prueba unitaria.

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 construcción de producción en primer lugar? Si no está probado, no lo dejes entrar, entonces no tendrás que trabajar los fines de semana)

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

1. "Hmmm, eso no está bien..."
2. Encontrar posible problema
3. Escribe una prueba, muestra que el código falla
4. Soluciona el problema
5. Mostrar que el nuevo código pasa
6. Bucle si el problema original persiste

Trato de hacer esto incluso mientras golpeo cosas, y lo hago casi al mismo tiempo, solo que con un conjunto de pruebas parcial ya en lugar.

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

Imagina que soy un programador simulado, llamado... Marco. Imagina que me gradué de la escuela no hace mucho tiempo, y nunca tuve que escribir exámenes. Imagina que trabajo en una empresa que realmente no hace cumplir o pide esto. OK? ¡bien! Ahora imagina, que la compañía está cambiando a usar pruebas, y están tratando de ponerme en línea con esto. Voy a dar una reacción algo sarcástica a los elementos mencionados hasta ahora, como si no hiciera ninguna investigación sobre esto.

Vamos a empezar con el creador:

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

¿Cómo puede escribir más, hacer las cosas más simples. Ahora tendría que estar pendiente de conseguir más casos, etc. Esto lo hace más complicado si me preguntas. Dame detalles sólidos.

Mostrándolo previene defectos.

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

Por lo que es un lo del ego diciendo que solo los malos programadores no lo hacen.

Ohh, así que piensas que soy un mal programador solo porque no hago tantas pruebas usadas. Estoy insultada y enojada contigo. Prefiero tener ayuda y apoyo que dichos.

@Justin Standard: En el inicio de un nuevo propecto empareja al chico junior contigo mismo u otro programador senior.

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

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

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

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

@Dominic Cooney: Pase algún 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 de nuevo.

@Dominic Cooney: Responde preguntas, ejemplos y libros.

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

@Adam Hayle : Revisión sorpresa.

Di qué, has soltado algo para lo que no estoy completamente preparado. Me siento incómodo con esto, pero haré lo mejor que pueda. Ahora estaré asustada y ligeramente aprensiva de que esto vuelva a ocurrir, gracias. Sin embargo, la táctica de miedo podría haber funcionado, pero tiene un costo. Sin embargo, si nada más funciona, esto podría ser solo el empuje que se necesita.

@Rytm: Los ítems 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 : Deshazte / Sacrificio.

glares, glares, glares - Hay una posibilidad de que pueda aprender, 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. Tener una persona que se tome su tiempo para ayudar, y hacerme comenzar a tener buenos hábitos siempre es bienvenido. Entonces, después de tener una buena red de soporte sería genial. Sería siempre se agradece que alguien venga un par de veces después, y repase algún código, para ver cómo todo está fluyendo, no en una revisión per se, sino más bien como una visita amistosa.

Razonamiento, Preparación, Enseñanza, Seguimiento, Apoyo.

He notado que muchos programadores ven el valor de probar en un nivel racional. Si has escuchado cosas como "sí, sé que debería probar esto, pero realmente necesito hacerlo rápidamente", entonces sabes a lo que me refiero. Sin embargo, a nivel emocional sienten que consiguen hacer algo solo cuando están escribiendo el código real.

El objetivo, entonces, debería ser de alguna manera hacerles entender que las pruebas son de hecho la única manera de medir cuando algo está "hecho", y así dales la motivación intrínseca para escribir pruebas.

Esto es lo que haría:

• Primera vez fuera... "vamos a hacer este proyecto conjuntamente. Voy a escribir las pruebas y tú 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... "¿Terminaste? ¡Órale! Primero echemos un vistazo a las pruebas que están impulsando su desarrollo. ¿No hay pruebas? Házmelo saber cuando esté hecho y vamos a reprogramar buscando en tu código. Si necesitas ayuda para formular las pruebas, avísame y te ayudaré."

Como programador junior, todavía estoy tratando de adquirir el hábito de escribir pruebas. Obviamente no es fácil adquirir nuevos hábitos, pero pensando en lo que haría que esto funcionara para mí, tengo que +1 los comentarios sobre las revisiones de código 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 próxima semana, y el próximo mes. Sólo digo eso porque al hojear las respuestas no vi que indicado.

Al hacer revisiones de código (si decides hacerlo), asegúrate de que tu joven desarrollador sepa que no se trata de menospreciarlo, se trata de mejorar el código. Porque de esa manera su confianza es menos probable que 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: [ Justin Standard ]

No pongas a ti mismo abajo, lo que tienes que decir es más o menos correcto.

En cuanto a 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 convierte en un proceso colaborativo.

Francamente, si usted está teniendo que poner que mucho esfuerzo en conseguir que haga algo, entonces usted puede tener que llegar a un acuerdo con el pensamiento de que puede simplemente no ser un buen ajuste para el equipo, y puede que tenga que ir. Ahora, esto no significa necesariamente despedirlo... puede significar encontrar otro lugar en la empresa sus habilidades son más adecuadas. Pero si no hay otro lugar...ya sabes qué hacer.

Asumo que también es un empleado bastante nuevo (

Si este es el caso, una cosa que he encontrado funciona es tener una especie de "sorpresa nueva revisión de alquiler."No importa si nunca lo has hecho antes...él no lo sabrá. Solo siéntate y dile que vas a repasar su actuación y mostrarle algunos números reales...tome su hoja de revisión normal (tiene una revisión formal ¿proceso correcto?) y cambia el encabezado si quieres para que parezca oficial y muéstrale dónde está. Si le muestra en un entorno muy formal que no hacer pruebas está afectando negativamente su calificación de rendimiento en lugar de solo "regañarlo" al respecto, con suerte obtendrá el punto. Tienes que demostrarle que sus acciones realmente lo afectarán ya sea en términos de pago o de otra manera.

Lo sé, es posible que desee mantenerse alejado de hacer esto porque no es oficial... pero creo que estás dentro razón para hacerlo y probablemente va a ser mucho más barato que tener que despedirlo y reclutar a alguien nuevo.

Ya está haciendo esto. Realmente. Simplemente no lo escribe. ¿No estás convencido? Míralo pasar por el ciclo de desarrollo estándar:

• Escribe un trozo de código
• Compilarlo
• Corre a ver qué hace
• Escriba el siguiente fragmento de código

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

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

Cuando no tenga una respuesta, pregunte: "¿Cómo le gustaría que su programa le dijera cuando un cambio rompe algo que funcionó ayer?"

De eso se trata la prueba unitaria automática.

Como programador junior, pensé que ese Id revelaría cómo fue cuando me encontré en una situación similar a su desarrollador junior.

Cuando salí por primera vez de la uni, descubrí que me había equipado para lidiar con el mundo real. Sí, sabía algunos conceptos 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 decirte que yo era probablemente uno de los vaqueros más grandes alrededor, me hackear juntos un poco de corrección de errores / algoritmo sin comentarios / pruebas / documentación y enviarlo por la puerta.

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

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

Puntos para llevarse a casa

1. La mayoría de las universidades son muy malas en la preparación de los estudiantes para el mundo real
2. La programación emparejada realmente me ayudó. Eso no quiere decir que va a ayudar a todos, pero que funcionó para mí.

Asígnelos a proyectos que no requieran "código estable de alta calidad" si eso es lo que le preocupa y deje que el desarrollador jr. falle. Que sean ellos los que 'vengan el fin de semana' para arreglar sus errores. Almuerce mucho y hable sobre las 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 asignen.

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

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

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, haga evidente que no verá avances y / o aumentos salariales si no mejora sus habilidades en las pruebas.

Al final, incluso con toda su ayuda, aliento, tutoría, podría no ser un ajuste para tu equipo, así que déjalo ir y busca a alguien que lo consiga.

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

Aunque no se si necesitas bloquear commits como ese. En mi lugar de trabajo, todo el mundo tiene un commit gratuito para todo, y todos los mensajes SVN commit (con diferencias) se envían por correo electrónico al equipo.

Nota: realmentedesea el complemento thunderbird colored-diffs si planea hacer esto.

Mi jefe o yo mismo (el 2 codificadores' senior') terminarán leyendo sobre las confirmaciones, y si hay algo como "olvidaste agregar pruebas unitarias", simplemente le enviamos un correo electrónico o vamos a chatear con la persona, explicando por qué necesitaba pruebas unitarias o lo que sea. Se anima a todos los demás a leer los commits también, ya que es una gran manera de ver lo que está pasando, pero los desarrolladores junior no comentan tanto.

Puedes ayudar a animar a la gente a adquirir el hábito de esto diciendo periódicamente cosas como " Oye, Bob, ¿viste eso commit que hice esta mañana, encontré este buen truco donde puedes hacer bla bla lo que sea, leer el commit y ver cómo funciona!"

NB: Tenemos 2 desarrolladores 'senior' y 3 junior. Esto puede no escalar, o es posible que tenga que ajustar el proceso un poco con más desarrolladores.

1. Haga que la cobertura de código sea parte de las revisiones.
2. Haga que "escribir una prueba que exponga el error" sea un prerrequisito para corregir un error.
3. Requiere un cierto nivel de cobertura antes de que el código se pueda registrar.
4. Encuentre un buen libro sobre el desarrollo basado en pruebas y utilícelo para mostrar cómo test-first puede acelerar el desarrollo.

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

Usted puede sofocar en cualquier términos que usted piensa que son apropiados, áspero o suave, no importa. Pero el hecho es que a los programadores no se les paga por simplemente juntar código y comprobarlo're se les paga por armar cuidadosamente código, luego armar pruebas, luego probar su código, LUEGO verificar todo. (Menos así es como suena, por tu descripción.)

Por lo tanto, si alguien va a negarse a hacer su trabajo, explíquele que puede quedarse en casa, mañana, y contratará a alguien que hará el trabajo.

De nuevo, puedes hacer todo esto suavemente, si crees que es necesario, pero mucha gente solo necesita una gran bofetada dura de La Vida En El Mundo Real, y les estarías haciendo un favor dándoselo.

Buena suerte.

Cambie la descripción de su trabajo por un tiempo para que solo esté escribiendo pruebas y manteniendo pruebas. He oído que muchas compañías hacen esto para gente nueva y fresca sin experiencia por un tiempo cuando comienzan.

Además, emita un desafío mientras esté en ese rol: Escriba pruebas que a) fallen en el código actual a) cumplan con los requisitos del software. Esperemos que le hará crear algunas pruebas sólidas y exhaustivas (mejorar el proyecto) y lo hará mejor en la escritura de pruebas para cuando él se reintegra en el desarrollo central.

Edit> cumple con 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.

Si su colega carece de experiencia escribiendo pruebas tal vez él o ella está teniendo dificultades para realizar pruebas más allá de situaciones simples, y eso se está manifestando como pruebas inadecuadas. Esto es lo que intentaría:

• Pase algún tiempo y comparta técnicas de prueba, como la inyección de dependencias, la búsqueda de casos extremos, etc. con su colega.
• Ofrezca responder preguntas sobre las pruebas.
• Haga revisiones de código de las pruebas por un tiempo. Pídale a su colega que revise los cambios suyos son ejemplos de buenas pruebas. Mira sus comentarios para ver si realmente están leyendo y entendiendo tu código de prueba.
• Si hay libros que encajan particularmente bien con la filosofía de pruebas de tu equipo, dale una copia. Podría ser útil que sus comentarios de revisión de código o discusiones hagan referencia al libro para que él o ella tenga un hilo para recoger y seguir.

No enfatizaría especialmente el factor vergüenza/culpa. Vale la pena señalar que las pruebas son un adoptado, buena práctica y que escribir y mantener buenas pruebas es una cortesía profesional para que tus compañeros de equipo no necesiten pasar sus fines de semana en el trabajo, pero yo no insistiría en esos puntos.

Si realmente necesitas "ponerte duro" entonces instituye un sistema imparcial; a nadie le gusta sentir que están siendo señalados. Por ejemplo, su equipo podría requerir código para mantener un cierto nivel de cobertura de prueba (capaz de ser jugado, pero al menos capaz de ser automatizado); requerir nuevo código para tener pruebas; exigir a los revisores que consideren la calidad de las pruebas al hacer revisiones de código; y así sucesivamente. La institución de ese sistema debe provenir del consenso del equipo. Si moderas la discusión cuidadosamente, podrías descubrir otras razones subyacentes por las que las pruebas de tu colega no son lo que esperas.

Es responsabilidad de su Mentor Enseñarle. Qué tan bien le estás enseñando CÓMO hacer pruebas. ¿Estás programando con él? Lo más probable es que el Junior no sepa cómo configurar una buena prueba para xyz.

Como estudiante de último año de la escuela conoce muchos Conceptos. Qué técnica. Algo de experiencia. Pero al final, todo un Junior es POTENCIAL. Casi todas las características en las que trabajan, habrá algo nuevo que nunca han hecho antes. Seguro que el Junior pudo haber hecho un patrón de estado simple para un proyecto en clase, abriendo y cerrando "puertas", pero nunca una aplicación del mundo real de los patrones.

Él/ella solo será tan bueno como lo bien que enseñes. Si fueran capaces de" Simplemente conseguirlo " ¿crees que habrían tomado una posición Junior en primer lugar?

En mi experiencia, a los jóvenes se les contrata y se les da casi la misma responsabilidad que a los Mayores, pero se les paga menos y luego se les ignora cuando comienzan a flaquear. Perdóname si parezco amargado, es porque lo soy.

@ jsmorris

Una vez el desarrollador senior y "arquitecto" me reprendió a mí y a un probador(fue mi primer trabajo fuera de la universidad) en un correo electrónico por no quedarse hasta tarde y terminar una tarea tan "fácil" la noche anterior. Habíamos estado en eso todo el día y lo dejamos a las 7 pm, había estado golpeando desde las 11 am antes del almuerzo de ese día y había molestado a cada miembro de nuestro equipo por ayuda al menos dos veces.

Respondí y cc'd el equipo con: "He estado decepcionado contigo durante un mes. Nunca consigo ayuda del equipo. Estaré en la cafetería de enfrente si me necesitas. Lo siento, no pude depurar el parámetro 12, el método de línea 800 del que casi todo depende."

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

"¿Entonces renuncias?"

En su repositorio de código fuente : use hooks antes de cada commit (pre-commit hook para SVN por ejemplo)

En ese hook, compruebe la existencia de al menos un caso de uso para cada método. Utilice una convención para la organización de pruebas unitarias que podría aplicar fácilmente a través de un gancho pre-commit.

En un servidor de integración compile todo y verifique regularmente la cobertura de prueba utilizando una herramienta de cobertura de prueba. Si la cobertura de prueba no es del 100% para un código, bloquea cualquier confirmación del desarrollador. Debería enviar el caso de prueba que cubre el 100% del código.

Solo las comprobaciones automáticas pueden escalar bien en un proyecto. No se puede comprobar todo a mano.

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

Recuerda : La gente nunca hace lo que esperas, siempre hacen lo que inspeccionas.

En primer lugar, como la mayoría de los encuestados aquí señalan, si el chico no ve el valor de las pruebas, no hay mucho que puedas hacer al respecto, y ya has señalado que no puedes despedirlo. Sin embargo, el fracaso no es una opción aquí, así que ¿qué pasa con las pocas cosas que puede hacer?

Si su organización es lo suficientemente grande como para tener más de 6 desarrolladores, recomiendo encarecidamente tener un departamento de Control de Calidad (incluso si es solo una persona para comenzar). Idealmente, usted debe tener un relació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 hayan enseñado formalmente las técnicas de control de calidad adecuadas.

La mayoría de las organizaciones cometen el error fatal de asignar los roles de prueba al nuevo empleado, la persona con la menor cantidad de exposición a su código ideally idealmente, los desarrolladores senior deben ser trasladados al rol de control de calidad, 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 va a encontrar el defecto porque generalmente no es un error de sintaxis (los que se recogen en la compilación), sino un error de lógica.y la misma lógica está trabajando cuando escriben la prueba como cuando escriben el código. No haga que la persona que desarrolló el código pruebe ese código find encontrarán menos errores que cualquier otra persona.

En su caso, si puede permitir el esfuerzo de trabajo redirigido, hacer de este chico nuevo el primer miembro de su equipo de control de calidad. Haz que lea "Pruebas de Software En El Mundo Real: Mejorando el Proceso", porque obviamente necesitará algo de entrenamiento en su nuevo papel. Si no le gusta, renunciará y tu problema seguirá resuelto.

Un enfoque un poco menos vengativo sería dejar que esta persona haga lo que es bueno en (estoy asumiendo que esta persona fue contratada porque en realidad son competentes en la parte de programación del trabajo) , y contratar a un probador o dos para hacer la prueba (los estudiantes universitarios a menudo tienen prácticas o términos "cooperativos", 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 gerente de desarrollador de software, porque tener el equipo de control de calidad informe al gerente que tiene como objetivo principal hacer el producto es un conflicto de intereses.

Si su organización es menor que 6, o no puede salirse con la suya creando un nuevo equipo, recomiendo programación emparejada (PP). No soy un converso total de todas las técnicas de programación extrema, pero definitivamente soy un creyente en la programación emparejada. Sin embargo, ambos miembros del equipo de programación emparejado tienen que ser dedicados, o simplemente no funciona. Tienen que seguir dos reglas: el inspector tiene que entender completamente lo que se está codificando en la pantalla o tiene que pedirle al codificador que lo explique; el codificador solo puede codificar lo que puede explicar no no "verás" o "confía en mí" o se tolerará el agitar la mano.

Solo recomiendo PP si su equipo es capaz de hacerlo, porque, como las pruebas, ninguna cantidad de vítores o amenazas persuadirá a un par de introvertidos llenos de ego a trabajar juntos si no se sienten cómodos haciéndolo. Sin embargo, encuentro que entre la elección de escribir especificaciones funcionales detalladas y hacer revisiones de código vs. programación emparejada, el PP generalmente gana.

Si PP no es para usted, entonces TDD es su mejor apuesta, pero solo si se toma literalmente. El desarrollo basado en pruebas significa que primero escribes las pruebas, ejecutas las pruebas para demostrar que realmente fallan, y luego escribes el código más simple para que funcione. La compensación es ahora que (debería) tener una colección de miles de pruebas, que también es código, y es tan probable que el código de producción contenga errores. Seré honesto, no soy un gran fan de TDD, principalmente por esta razón, pero funciona para muchos desarrolladores que prefieren escribir scripts de prueba que documentos de casos de prueba some algunas pruebas es mejor que nada. Combine TDD con PP para una mejor probabilidad de cobertura de prueba y menos errores en el script.

Si todo lo demás falla, tienen los programadores de equivalencia de un juro frasco, cada vez que el programador se rompe la generación, tienen que poner $20, $50, $100 (lo que es moderadamente doloroso para su personal) en un frasco que va a su favorito (registrado!) caridad. Hasta que paguen, eviten:)

Dejando de lado las bromas, la mejor manera de hacer que tu programador escriba pruebas es no deja que programe. Si quieres un programador, contrata a un programador hire si quieres pruebas, contrata a un probador. Empecé como programador junior hace 12 años haciendo pruebas, y se convirtió en mi carrera, 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.

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 que quede claro: negarse a seguir las prácticas de desarrollo de la casa (incluyendo pruebas de escritura) y comprobar en el código de errores que otras personas tienen que limpiar con el tiempo hará que usted despedido.

La razón principal por la que los ingenieros/programadores junior no toman mucho tiempo para diseñar y realizar scripts de prueba, es porque la mayoría de las certificaciones CS no requieren esto en gran medida, 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 conseguir que los profesionales junior entren en el hábito, es hacerlo parte del proceso explícitamente. Es decir, al estimar el tiempo que una iteración debe tomar, el tiempo de diseño, escritura y / o execute the cases should be incorporated into this time estimate.

Finalmente, la revisión del 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 pruebas adecuadas de cada línea de código que escribe, y que el ingeniero superior y los compañeros sean responsables de proporcionar retroalimentación y orientación sobre el código y la prueba escrita.

Basado en tu comentario, "Mostrando que el diseño se vuelve más simple" asumo que ustedes practican TDD. Hacer una revisión de código después del hecho no va a funcionar. Todo el asunto sobre TDD es que es un diseño y no una filosofía 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. Va a terminar perdiendo un montón de casos de esquina y su código seguirá siendo crappy.

Su mejor apuesta es tener un muy desarrollador senior paciente para sentarse con él y hacer algunos pares de programación. Y sigue hasta que aprenda. O no aprende, en cuyo caso necesitas reasignarlo a una tarea para la que sea más adecuado porque terminarás frustrando a tus 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 en el "Equipo A" y personas en el "Equipo B". Los miembros del equipo A son los que diseñan la solución, escriben todo el código de producción no trivial y se comunican con los propietarios de negocios, todo el trabajo que requiere pensar fuera de la caja. El B-Team se encarga de cosas como la gestión de la configuración, escribir scripts, corregir errores lame, y hacer el trabajo de mantenimiento - todo el trabajo que tiene procedimientos estrictos que tienen pequeñas consecuencias para el fracaso.