Como fazer os programadores juniores escreverem testes? [fechadas]

Temos um programador júnior que simplesmente não escreve testes suficientes.
Eu tenho que importuná-lo a cada duas horas, "você escreveu testes?"
Nós tentamos:

• Mostrando que o design fica mais simples
• Mostrar evita defeitos
• Tornando isso uma coisa do ego, dizendo que apenas os programadores ruins não
• Este fim de semana, 2 membros da equipe tiveram que trabalhar porque seu código tinha uma referência NULL e ele não o testou

Meu trabalho requer código estável de alta qualidade e geralmente todos 'entendem' e não há necessidade de forçar os testes. Sabemos que podemos fazer com que ele escreva testes, mas todos sabemos que os testes úteis são aqueles escritos quando você está interessado.

Você conhece mais motivações?

Esta é uma das coisas mais difíceis de fazer. Obtendo o seu povo para obtê-lo .

Às vezes, uma das melhores maneiras de ajudar os programadores de nível júnior a "entender" e aprender as técnicas certas com os mais velhos é fazer um pouco de programação em pares.

Experimente o seguinte: em um projeto futuro, coloque o cara júnior com você ou outro programador sênior. Eles devem trabalhar juntos, revezando-se "dirigindo" (sendo aquele que digita no teclado) e "treinando" (olhando por cima do ombro do motorista e apontando sugestões, erros, etc, conforme eles vão). Pode parecer um desperdício de recursos, mas você encontrará:

1. Que esses caras juntos podem produzir código muito rápido e de qualidade superior.
2. Se o seu cara júnior aprender o suficiente para "entender" com um cara mais velho o direcionando pelo caminho certo (por exemplo, "Ok, agora antes de continuarmos, vamos escrever um teste para esta função"). Valerá a pena os recursos que você comprometa-se com isso.

Talvez também peça a alguém do seu grupo para fazer a apresentação do Unit Testing 101, de Kate Rhodes. Acho que é uma ótima maneira de deixar as pessoas entusiasmadas com o teste, se bem realizada.

Outra coisa que você pode fazer é fazer com que seus Jr. Devs pratiquem o Bowling Game Kata, que os ajudará a aprender Desenvolvimento Orientado a Testes. Está em java, mas pode ser facilmente adaptado para qualquer idioma.

Faça uma revisão do código antes de cada confirmação (mesmo que seja um "Eu mudei o nome desta variável" de 1 minuto) e, como parte da revisão do código, analise todos os testes de unidade.

Não assine o commit até que os testes estejam concluídos.

(Além disso - se o trabalho dele não foi testado - por que estava em uma versão de produção em primeiro lugar? Se não for testado, não deixe entrar, então você não terá que trabalhar nos fins de semana)

Para mim, comecei a insistir que cada bug que encontrar e corrigir seja expresso como um teste:

1. "Hmmm, isso não está certo ..."
2. Encontre possível problema
3. Escreva um teste, mostre que o código falha
4. Corrigir o problema
5. Mostre que o novo código passa
6. Loop se o problema original persistir

Tento fazer isso mesmo enquanto estou trabalhando, e consigo terminar quase ao mesmo tempo, apenas com um conjunto de testes parcial já instalado.

(Eu não vivo em um ambiente de programação comercial e geralmente sou o único programador trabalhando em um projeto específico.)

Imagine que eu sou um programador simulado, chamado ... Marco. Imagine que eu me formei na escola não faz muito tempo e nunca precisei escrever testes. Imagine que eu trabalho em uma empresa que realmente não impõe ou pede por isso. OK? Boa! Agora imagine que a empresa está começando a usar testes e estão tentando me colocar em linha com isso. Vou dar uma reação um tanto sarcástica aos itens mencionados até agora, como se eu não tivesse feito nenhuma pesquisa sobre isso.

Vamos começar com o criador:

Mostrando que o design fica mais simples.

Como escrever mais, tornar as coisas mais simples. Eu agora teria que ficar de olho na obtenção de mais casos, etc. Isso torna mais complicado se você me perguntar. Dê-me detalhes sólidos.

Mostrar evita defeitos.

Eu sei disso. É por isso que são chamados de testes. Meu código é bom e verifiquei se há problemas, então não vejo onde esses testes podem ajudar.

Tornar isso uma coisa do ego dizer que apenas os programadores ruins não o fazem.

Ohh, então você acha que sou um mau programador só porque não faço testes tão usados. Estou insultado e positivamente irritado com você. Eu prefiro ter assistência e apoio do que dizeres.

@ Justin Standard : No início de um novo par de propósitos, o cara júnior fica com você ou outro programador sênior.

Ohh, isso é tão importante que recursos serão gastos para garantir que eu veja como as coisas são feitas e alguns me ajudem sobre como as coisas são feitas. Isso é útil, e posso começar a fazer mais.

@ Justin Standard : Leia a apresentação do Unit Testing 101 por Kate Rhodes.

Ahh, foi uma apresentação interessante e me fez pensar em testar. Isso martelou alguns pontos que eu deveria considerar e pode ter influenciado um pouco minhas opiniões.

Eu adoraria ver artigos mais atraentes e outras ferramentas para me ajudar a entender que essa é a maneira certa de fazer as coisas.

@ Dominic Cooney : Passe algum tempo compartilhando técnicas de teste.

Ahh, isso me ajuda a entender o que se espera de mim em relação às técnicas, e coloca mais itens na minha sacola de conhecimento, que posso usar novamente.

@ Dominic Cooney : Responda a perguntas, exemplos e livros.

Ter uma pessoa indicada (pessoas) para responder à pergunta é útil, pode me tornar mais propenso a tentar. Bons exemplos são ótimos e me dão algo em que buscar e algo para procurar como referência. Os livros que são relevantes para isso diretamente são uma grande referência.

@ Adam Hayle : Revisão surpresa.

Diga, você criou algo para o qual estou completamente despreparado. Eu me sinto desconfortável com isso, mas farei o meu melhor. Agora vou ficar com medo e um pouco apreensivo de que isso aconteça novamente, obrigado. No entanto, a tática do susto pode ter funcionado, mas tem um custo. No entanto, se nada mais funcionar, esse pode ser apenas o push necessário.

@ Rytmis : Os itens só são considerados concluídos quando têm casos de teste.

Ohh, interessante. Vejo que realmente preciso fazer isso agora, caso contrário, não estou concluindo nada. Isso faz sentido.

@ jmorris : Livre-se / Sacrifique.

clarões, clarões, clarões - Há uma chance de eu aprender, e com apoio e assistência, posso me tornar uma parte muito importante e funcional das equipes. Esta é uma das minhas deficiências agora, mas não será por muito tempo. No entanto, se eu simplesmente não entender, entendo que irei. Acho que vou conseguir.

No final, o apoio da minha equipe teve um papel importante em tudo isso. É sempre bem-vindo que uma pessoa dedique seu tempo para me ajudar e começar a ter bons hábitos. Então, depois disso, ter uma boa rede de apoio seria ótimo. Sempre seria apreciado se alguém viesse algumas vezes depois e revisse algum código, para ver como tudo está fluindo, não em uma revisão em si, mas mais como uma visita amigável.

Raciocínio, Preparação, Ensino, Acompanhamento, Apoio.

Percebi que muitos programadores veem o valor de testar em um nível racional. Se você já ouviu coisas como "sim, eu sei que deveria testar isso, mas eu realmente preciso fazer isso rápido", então você sabe o que quero dizer. No entanto, em um nível emocional, eles sentem que fazem algo apenas quando estão escrevendo o código real.

O objetivo, então, deve ser de alguma forma fazê-los entender que o teste é, de fato, a única maneira de medir quando algo está "feito" e, assim, dar a eles a motivação intrínseca para escrever testes.

Receio que isso seja muito mais difícil do que deveria ser, no entanto. Você ouvirá muitas desculpas do tipo "Estou com muita pressa, vou reescrever / refatorar isso mais tarde e adicionar os testes" - e, claro, o acompanhamento nunca acontece porque, surpreendentemente, eles estarei tão ocupado na próxima semana .

Aqui está o que eu faria:

• Primeira vez ... "vamos fazer este projeto juntos. Vou escrever os testes e você vai escrever o código. Preste atenção em como escrevo os testes, porque é assim que fazemos as coisas por aqui e é isso que espero de você. "

• Seguindo isso ... "Pronto? Ótimo! Primeiro, vamos dar uma olhada nos testes que estão impulsionando o seu desenvolvimento. Oh, nenhum teste? Avise-me quando isso for feito e vamos reagendar a análise do seu código. está precisando de ajuda para formular os testes me avise e eu te ajudarei. "

Ele já está fazendo isso. Realmente. Ele simplesmente não escreve. Não convencido? Observe-o passar pelo ciclo de desenvolvimento padrão:

• Escreva um trecho de código
• Compilar
• Corra para ver o que faz
• Escreva a próxima parte do código

A etapa 3 é o teste. Ele já faz testes, só faz manualmente. Faça-lhe esta pergunta: "Como você sabe amanhã se o código de hoje ainda funciona?" Ele responderá: "É uma pequena quantidade de código!"

Pergunte: "Que tal na próxima semana?"

Quando ele não tiver uma resposta, pergunte: "Como você gostaria que seu programa avisasse quando uma mudança interromper algo que funcionou ontem?"

É disso que se trata o teste de unidade automático.

Como um programador júnior, ainda estou tentando adquirir o hábito de escrever testes. Obviamente não é fácil adquirir novos hábitos, mas pensando no que faria isso funcionar para mim, eu tenho que marcar com +1 os comentários sobre revisões de código e coaching / programação em pares.

Também pode valer a pena enfatizar o propósito de longo prazo do teste: garantir que o que funcionou ontem ainda funcione hoje, na próxima semana e no próximo mês. Só digo isso porque, ao passar os olhos pelas respostas, não vi isso mencionado.

Ao fazer revisões de código (se você decidir fazer isso), certifique-se de que seu jovem desenvolvedor saiba que não se trata de rebaixá-lo, mas de tornar o código melhor. Porque dessa forma sua confiança tem menos probabilidade de ser prejudicada. E isso é importante. Por outro lado, saber o quão pouco você sabe também é.

Claro, eu realmente não sei nada. Mas espero que as palavras tenham sido úteis.

Editar: [ Justin Standard ]

Não se rebaixe, o que você tem a dizer é bastante correto.

Sobre o seu ponto sobre revisões de código: o que você descobrirá é que não apenas o desenvolvedor júnior aprenderá no processo, mas também os revisores. Todos em uma revisão de código aprendem se você fizer disso um processo colaborativo.

Francamente, se você está tendo que se esforçar tanto para fazer com que ele faça algo, então você pode ter que aceitar o pensamento de que ele pode simplesmente não ser uma boa opção para a equipe e pode precisar ir. Agora, isso não significa necessariamente demiti-lo ... pode significar encontrar outro lugar na empresa em que suas habilidades sejam mais adequadas. Mas se não houver outro lugar ... você sabe o que fazer.

Presumo que ele também seja um contratado relativamente novo (<1 ano) e provavelmente saiu da escola recentemente ... nesse caso, ele pode não estar acostumado a como as coisas funcionam em um ambiente corporativo. Coisas assim a maioria de nós poderia se safar na faculdade.

Se for esse o caso, uma coisa que descobri que funciona é fazer uma espécie de "avaliação surpresa de novas contratações". Não importa se você nunca fez isso antes ... ele não saberá disso. Basta sentar-se com ele e dizer-lhe que irá rever o seu desempenho e mostrar-lhe alguns números reais ... pegue a sua folha de revisão normal (tem um processo de revisão formal, certo?) E altere o título se quiser para que pareça oficial e mostrar a ele onde ele está. Se você mostrar a ele em um ambiente muito formal que não fazer testes está afetando negativamente sua classificação de desempenho, ao invés de apenas "importuná-lo" sobre isso, ele esperançosamente entenderá. Você tem que mostrar a ele que suas ações irão realmente afetá-lo, seja em termos de pagamento ou não.

Eu sei, você pode querer ficar longe de fazer isso porque não é oficial ... mas acho que você tem razão para fazer isso e provavelmente vai ser muito mais barato do que ter de despedi-lo e recrutar alguém novo.

Como um programador júnior, pensei que revelaria como foi quando me encontrei em uma situação semelhante ao seu desenvolvedor júnior.

Quando saí da universidade, descobri que ela havia me despreparado para lidar com o mundo real. Sim, eu sabia alguns fundamentos de JAVA e alguma filosofia (não pergunte), mas era só isso. Quando comecei meu emprego, foi um pouco assustador, para dizer o mínimo. Deixe-me dizer que eu provavelmente era um dos maiores cowboys por aí, eu iria hackear juntos uma pequena correção de bug / algoritmo sem comentários / testes / documentação e enviar para fora da porta.

Tive a sorte de estar sob a supervisão de um programador sênior gentil e muito paciente. Felizmente para mim, ele decidiu sentar-se comigo e passar 1-2 semanas examinando meu código togethor muito hackeado. Ele explicaria onde eu errei, os pontos mais delicados de ce ponteiros (o menino fez isso me confundiu!). Conseguimos escrever uma aula / módulo bastante decente em cerca de uma semana. Tudo o que posso dizer é que se o dev sênior não tivesse investido tempo para me ajudar no caminho certo, eu provavelmente não teria durado muito.

Felizmente, daqui a 2 anos, espero que alguns dos meus colegas me considerem um programador mediano.

Ganhe pontos para casa

1. A maioria das universidades é muito ruim em preparar alunos para o mundo real
2. A programação em pares realmente me ajudou. Isso não quer dizer que vai ajudar a todos, mas funcionou para mim.

Atribua-os a projetos que não requerem "código estável de alta qualidade" se essa for a sua preocupação e deixe o jr. falha do desenvolvedor. Faça com que eles "venham no fim de semana" para consertar seus bugs. Almoce bastante e converse sobre práticas de desenvolvimento de software (não palestras, mas discussões). Com o tempo, eles irão adquirir e desenvolver as melhores práticas para realizar as tarefas que lhes são atribuídas.

Quem sabe, eles podem até inventar algo melhor do que as técnicas que sua equipe usa atualmente.

Se o programador júnior, ou qualquer outra pessoa, não vê o valor do teste, então será difícil fazer com que eles o façam ... ponto final.

Eu teria feito o programador júnior sacrificar seu fim de semana para consertar o bug. Suas ações (ou falta delas) não o estão afetando diretamente. Além disso, deixe claro que ele não verá avanços e / ou aumentos salariais se não melhorar suas habilidades em testes.

No final, mesmo com toda a sua ajuda, incentivo, orientação, ele pode não ser adequado para sua equipe, então deixe-o ir e procurar alguém que consiga.

Concordo com o comentário de RodeoClown sobre a revisão do código de cada commit. Depois de fazer isso algumas vezes, ele adquirirá o hábito de testar as coisas.

Não sei se você precisa bloquear commits assim. No meu local de trabalho, todos têm um commit livre para tudo, e todas as mensagens de commit SVN (com diffs) são enviadas por email para a equipe.

Nota: você realmente quer o complemento thunderbird colored-diffs se planeja fazer isso.

Meu chefe ou eu (os 2 programadores 'sênior') acabaremos lendo os commits, e se houver alguma coisa como "você se esqueceu de adicionar testes de unidade", simplesmente enviamos um e-mail ou conversamos com a pessoa, explicando por que ela testes de unidade necessários ou o que quer. Todos os outros são encorajados a ler os commits também, pois é uma ótima maneira de ver o que está acontecendo, mas os desenvolvedores juniores não comentam muito.

Você pode ajudar a encorajar as pessoas a adquirirem o hábito disso dizendo periodicamente coisas como "Ei, bob, você viu aquele commit que eu fiz esta manhã, eu encontrei este truque legal onde você pode fazer blá, blá tudo, leia o commit e veja como funciona!"

NB: Temos 2 desenvolvedores 'sênior' e 3 juniores. Isso pode não escalar ou você pode precisar ajustar um pouco o processo com mais desenvolvedores.

1. Faça a cobertura do código parte das revisões.
2. Faça "escrever um teste que expõe o bug" um pré-requisito para consertar um bug.
3. Exigir um determinado nível de cobertura antes que o código possa ser verificado.
4. Encontre um bom livro sobre desenvolvimento orientado a teste e use-o para mostrar como o teste inicial pode acelerar o desenvolvimento.

Muita psicologia e técnicas úteis de "mentoreamento", mas, com toda a franqueza, isso se resume a "escrever testes se você ainda quiser ter um emprego amanhã".

Você pode expressá-lo em quaisquer termos que achar apropriados, severos ou suaves, não importa. Mas o fato é que os programadores não são pagos para apenas juntar o código e fazer o check-in - eles são pagos para montar o código cuidadosamente, depois montar os testes, testar o código, ENTÃO verificar tudo. (Pelo menos é o que parece, de acordo com sua descrição.)

Portanto, se alguém vai se recusar a fazer o trabalho, explique que ele pode ficar em casa amanhã, e você contratará alguém que FARÁ o serviço.

Novamente, você pode fazer tudo isso com cuidado, se achar que é necessário, mas muitas pessoas só precisam de um grande tapa forte de Life In The Real World , e você estaria fazendo um favor a elas se desse a elas.

Boa sorte.

Mude a descrição de seu trabalho por um tempo para apenas escrever testes e mantê-los. Ouvi dizer que muitas empresas fazem isso para pessoas novas e inexperientes por um tempo, quando começam.

Além disso, lance um desafio enquanto ele estiver nessa função: Escrever testes que irão a) falhar no código atual a) cumprir os requisitos do software. Esperançosamente, isso fará com que ele crie alguns testes sólidos e completos (melhorando o projeto) e o torne melhor na escrita de testes para quando ele se reintegrar ao desenvolvimento do núcleo.

edit> cumpre os requisitos do software, o que significa que ele não está apenas escrevendo testes para quebrar o código propositalmente quando o código nunca teve a intenção ou necessidade de levar aquele caso de teste em consideração.

Se o seu colega não tiver experiência em escrever testes, talvez ele esteja tendo dificuldade em fazer testes além de situações simples, e isso se manifesta como testes inadequados. Aqui está o que eu tentaria:

• Passe algum tempo e compartilhe técnicas de teste, como injeção de dependência, procura de casos extremos e assim por diante com seu colega.
• Ofereça-se para responder a perguntas sobre testes.
• Faça revisões de código de testes por um tempo. Peça ao seu colega para revisar as suas alterações que são exemplos de bons testes. Observe os comentários deles para ver se eles estão realmente lendo e entendendo seu código de teste.
• Se houver livros que se encaixem particularmente bem com a filosofia de teste de sua equipe, dê a ele uma cópia. Pode ajudar se seu feedback de revisão de código ou discussões fizerem referência ao livro para que ele ou ela tenha um tópico para escolher e seguir.

Eu não enfatizaria especialmente o fator vergonha / culpa. Vale ressaltar que o teste é uma boa prática amplamente adotada e que escrever e manter bons testes é uma cortesia profissional para que seus companheiros de equipe não precisem passar os fins de semana no trabalho, mas eu não insistiria nesses pontos.

Se você realmente precisa "ser duro", institua um sistema imparcial; ninguém gosta de se sentir destacado. Por exemplo, sua equipe pode exigir código para manter um certo nível de cobertura de teste (capaz de ser jogado, mas pelo menos capaz de ser automatizado); requer novo código para ter testes; exige que os revisores considerem a qualidade dos testes ao fazer revisões de código; e assim por diante. A instituição desse sistema deve vir do consenso da equipe. Se moderar a discussão com cuidado, você pode descobrir outras razões subjacentes que o teste de seu colega não é o que você esperava.

É responsabilidade do seu Mentor ensiná-lo. Você está ensinando bem como fazer o teste. Você está programando em par com ele? O Junior provavelmente não sabe COMO fazer um bom teste para xyz.

Como um jovem recém-saído da escola, ele conhece muitos conceitos. Alguma técnica. Alguma experiência. Mas no final, tudo que um Junior é POTENCIAL. Em quase todos os recursos em que trabalham, haverá algo novo que eles nunca fizeram antes. Claro, o Junior pode ter feito um padrão de estado simples para um projeto em sala de aula, abrindo e fechando "portas", mas nunca uma aplicação dos padrões no mundo real.

Ele / ela só será bom se você ensinar bem. Se eles fossem capazes de "Just get it", você acha que eles teriam assumido uma posição júnior em primeiro lugar?

Na minha experiência, os juniores são contratados e recebem quase as mesmas responsabilidades dos idosos, mas recebem menos e são ignorados quando começam a vacilar. Perdoe-me se pareço amargo, é porque estou.

@ jsmorris

Certa vez, o desenvolvedor sênior e o "arquiteto" censuraram a mim e a um testador (foi meu primeiro emprego depois da faculdade) por e-mail por não ficar até tarde e terminar uma tarefa tão "fácil" na noite anterior. Tínhamos estado nisso o dia todo e encerramos às 19h. Eu estava me debatendo desde as 11h antes do almoço naquele dia e importunei todos os membros de nossa equipe por ajuda pelo menos duas vezes.

Respondi com cópia para a equipe: "Estou decepcionado com você há um mês. Nunca recebo ajuda da equipe. Estarei no café do outro lado da rua se precisar de mim. Estou desculpe, eu não pude depurar o método de 12 parâmetros e 800 linhas do qual quase tudo depende. "

Depois de me refrescar na cafeteria por uma hora, voltei para o escritório, peguei minhas merdas e saí. Depois de alguns dias eles me ligaram perguntando se eu iria, eu disse que sim, mas tinha uma entrevista, talvez amanhã.

"Então, você está desistindo?"

Em seu repositório de origem: use ganchos antes de cada commit (gancho pré-commit para SVN, por exemplo)

Nesse gancho, verifique a existência de pelo menos um caso de uso para cada método. Use uma convenção para a organização de teste de unidade que você possa facilmente impor por meio de um gancho de pré-confirmação.

Em um servidor de integração, compile tudo e verifique regularmente a cobertura de teste usando uma ferramenta de cobertura de teste. Se a cobertura do teste não for 100% para um código, bloqueie qualquer commit do desenvolvedor. Ele deve enviar a você o caso de teste que cobre 100% do código.

Somente verificações automáticas podem escalar bem em um projeto. Você não pode verificar tudo manualmente.

O desenvolvedor deve ter um meio para verificar se seus casos de teste cobrem 100% do código. Dessa forma, se ele não cometer um código 100% testado, é sua própria culpa, não uma falha "ops, desculpe, eu esqueci".

Lembre-se: as pessoas nunca fazem o que você espera, elas sempre fazem o que você inspeciona.

Em primeiro lugar, como a maioria dos entrevistados aqui apontou, se o cara não vê o valor do teste, não há muito que você possa fazer sobre isso, e você já apontou que não pode demitir o cara. No entanto, o fracasso não é uma opção aqui, então o que dizer das poucas coisas que você pode fazer?

Se sua organização é grande o suficiente para ter mais de 6 desenvolvedores, recomendo fortemente ter um departamento de Garantia de Qualidade (mesmo que seja apenas uma pessoa para começar). Idealmente, você deve ter uma proporção de 1 testador para 3-5 desenvolvedores. O que acontece com os programadores é ... eles são programadores, não testadores. Ainda não entrevistei um programador que tenha aprendido formalmente as técnicas adequadas de controle de qualidade.

A maioria das organizações comete a falha fatal de atribuir as funções de teste ao recém-contratado, a pessoa com MENOS exposição ao seu código - de preferência, os desenvolvedores seniores devem ser transferidos para a função de QA, pois têm experiência no código e (com sorte) desenvolveram um sexto sentido para odores de código e pontos de falha que podem surgir.

Além disso, o programador que cometeu o erro provavelmente não encontrará o defeito porque geralmente não é um erro de sintaxe (aqueles são detectados na compilação), mas um erro de lógica - e a mesma lógica está em funcionamento quando eles escrevem o teste como quando escrevem o código. Não deixe a pessoa que desenvolveu o código testar esse código - eles encontrarão menos bugs do que qualquer outra pessoa.

No seu caso, se você puder pagar o esforço de trabalho redirecionado, torne esse novo cara o primeiro membro de sua equipe de QA. Faça com que ele leia "Teste de software no mundo real: melhorando o processo", porque ele obviamente precisará de algum treinamento em sua nova função. Se ele não gostar, ele desiste e o seu problema ainda está resolvido.

Uma abordagem um pouco menos vingativa seria deixar essa pessoa fazer o que é bom (estou assumindo que essa pessoa foi contratada porque é realmente competente na parte de programação do trabalho) e contratar um testador ou dois para fazer o teste ( Estudantes universitários costumam ter estágio ou termos de "cooperação", adorariam a exposição e são baratos)

Nota lateral: Eventualmente, você vai querer que a equipe de QA se reporte a um diretor de QA, ou pelo menos não a um gerente de desenvolvedor de software, porque ter a equipe de QA se reportar ao gerente cujo objetivo principal é fazer o produto terminar é um conflito de interesse.

Se sua organização for menor que 6, ou você não conseguir criar uma nova equipe, recomendo a programação em pares (PP). Não sou totalmente convertido em todas as técnicas extremas de programação, mas definitivamente acredito na programação em pares. No entanto, ambos os membros da equipe de programação emparelhada precisam ser dedicados, ou simplesmente não funciona. Eles têm que seguir duas regras: o inspetor tem que entender completamente o que está sendo codificado na tela ou tem que pedir ao codificador para explicar; o codificador só pode codificar o que ele pode explicar - nenhum "você verá" ou "confie em mim" ou acenos de mão serão tolerados.

Eu só recomendo PP se sua equipe for capaz disso, porque, como nos testes, nenhuma quantidade de aplausos ou ameaças irá persuadir alguns introvertidos cheios de ego a trabalharem juntos se eles não se sentirem confortáveis ​​em fazer isso. No entanto, acho que entre a escolha de escrever especificações funcionais detalhadas e fazer revisões de código versus programação em pares, o PP geralmente vence.

Se PP não for para você, então TDD é sua melhor aposta, mas apenas se for interpretado literalmente. Desenvolvimento Orientado a Testes significa que você escreve os testes PRIMEIRO, executa os testes para provar que eles realmente falham e, em seguida, escreve o código mais simples para fazê-lo funcionar. A desvantagem agora é que você (deveria) ter uma coleção de milhares de testes, que também é código, e é tão provável que o código de produção contenha bugs. Vou ser honesto, não sou um grande fã de TDD, principalmente por esse motivo, mas ele funciona para muitos desenvolvedores que preferem escrever scripts de teste do que documentos de caso de teste - alguns testes são melhores do que nenhum. Junte TDD com PP para uma melhor probabilidade de cobertura de teste e menos bugs no script.

Se tudo mais falhar, tenha a equivalência de programadores de um jarro de juramento - cada vez que o programador quebra a compilação, eles têm que colocar $ 20, $ 50, $ 100 (o que for moderadamente doloroso para sua equipe) em um jar que vai para o seu favorito ( registrado!) caridade. Até que eles paguem, evite-os :)

Brincadeiras à parte, a melhor maneira de fazer seu programador escrever testes é não deixá-lo programar. Se você quer um programador, contrate um programador - Se você quiser testes, contrate um testador. Comecei como programador júnior há 12 anos fazendo testes e isso se tornou minha carreira, e eu não trocaria isso por nada. Um departamento de QA sólido que seja devidamente nutrido e com o poder e a ordem para melhorar o software é tão valioso quanto os desenvolvedores que escreveram o software em primeiro lugar.

Isso pode ser um pouco cruel, mas da maneira como você descreve a situação, parece que você precisa demitir esse cara. Ou, pelo menos, deixe claro: recusar-se a seguir as práticas de desenvolvimento da casa (incluindo escrever testes) e verificar o código com erros que outras pessoas precisam limpar acabará fazendo com que você seja demitido.

O principal motivo pelo qual os engenheiros / programadores juniores não gastam muito tempo para projetar e executar scripts de teste é porque a maioria das certificações CS não exige muito isso, então outras áreas da engenharia são cobertas mais adiante em programas universitários, como padrões de design.

Na minha experiência, a melhor maneira de fazer com que os profissionais juniores se tornem habituais é torná-lo parte do processo explicitamente. Ou seja, ao estimar o tempo que uma iteração deve levar, o tempo de projetar, escrever e / ou executar os casos deve ser incorporado a esta estimativa de tempo.

Por fim, a revisão do design do script de teste deve ser parte de uma revisão de design e o código real deve ser revisado na revisão do código. Isso torna o programador responsável por fazer o teste adequado de cada linha de código que ele escreve, e o engenheiro sênior e seus colegas são responsáveis ​​por fornecer feedback e orientação sobre o código e o teste escrito.

Com base em seu comentário, "Mostrando que o design se torna mais simples", estou assumindo que vocês praticam TDD. Fazer uma revisão de código após o fato não vai funcionar. A coisa toda sobre TDD é que é um design e não uma filosofia de teste. Se ele não escreveu os testes como parte do design, você não terá muitos benefícios em escrever testes depois do fato - especialmente de um desenvolvedor júnior. Ele vai acabar perdendo um monte de casos esquivos e seu código ainda será uma merda.

Sua melhor aposta é ter um desenvolvedor sênior muito paciente para sentar com ele e fazer alguma programação em pares. E continue assim até que ele aprenda. Ou não aprende, caso em que você precisa reatribuí-lo a uma tarefa para a qual ele é mais adequado, porque você acabará frustrando seus desenvolvedores reais.

Nem todos têm o mesmo nível de talento e / ou motivação. Equipes de desenvolvimento, mesmo as ágeis, são compostas por pessoas do "A-Team" e pessoas do "B-Team". Os membros do A-Team são aqueles que arquitetam a solução, escrevem todo o código de produção não trivial e se comunicam com os proprietários de negócios - todo o trabalho que requer pensar fora da caixa. O B-Team lida com coisas como gerenciamento de configuração, escrever scripts, consertar bugs lame e fazer trabalho de manutenção - todo o trabalho que tem procedimentos rígidos que têm pequenas consequências para falhas.