Como fazer júnior, os programadores escrevem testes?[fechado]

https://stackoverflow.com/questions/7252

08-06-2019
|

Pergunta

Temos um programador júnior, que simplesmente não escrever testes suficientes.
Eu tenho a nag-lo a cada duas horas, você "testes escritos?"
Tentámos:

Mostrando que o design se torna mais simples
Mostrando previne defeitos
Tornando-se uma coisa de ego dizendo apenas maus programadores não
Este fim-de-semana de 2 membros da equipe tinham para chegar ao trabalho porque o seu código havia uma referência NULA, e ele não testá-lo

Meu trabalho requer superior qualidade código estável, e, geralmente, todo mundo tem " e que não há necessidade de empurrar através de testes.Sabemos que podemos fazê-lo escrever testes, mas todos nós sabemos o útil testes são aqueles escritos quando você estiver nele.

Você sabe de mais motivações?

Solução

Este é um dos as coisas mais difíceis para o fazer.Obtendo o seu povo para obtê-lo.

Às vezes, uma das melhores maneiras para ajudar junior programadores de nível 'get it' e aprender as técnicas corretas de idosos é fazer um pouco de programação em par.

Tente isso:em um próximo projeto, par junior cara com si mesmo ou a outro programador sênior.Eles devem trabalhar juntos, revezando-se "condução" (sendo a escrever a eles teclado) e "coaching" (olhando por cima do ombro do motorista e apontando sugestões, erros, etc, como eles vão).Pode parecer um desperdício de recursos, mas você vai encontrar:

Que esses caras juntos podem produzir um código muito rápido e de maior qualidade.
Se sua júnior cara aprende o suficiente para "pegar" com um sênior cara dirigindo-lo ao longo do caminho (ex."Ok, agora antes de continuar, permite gravação de teste para esta função.") Vai valer a pena os recursos que você comprometer-se a ele.

Talvez tenha alguém no seu grupo dar a Os Testes De Unidade 101 apresentação por Kate Rhodes, eu acho que é uma ótima maneira de fazer as pessoas se interessarem sobre o teste, se entregue.

Outra coisa que você pode fazer é ter o seu Jr.Devs prática o Jogo De Boliche Kata o que irá ajudá-los a aprender Test Driven Development.Ele é em java, mas pode ser facilmente adaptado para qualquer idioma.

Outras dicas

Ter uma revisão do código, antes de cada commit (mesmo se ele for um 1 minuto ", eu mudei esse nome de variável"), e como parte da revisão de código, revisão de qualquer dos testes de unidade.

Não assinar a cometer até os testes estão no lugar.

(Também Se seu trabalho não foi testado - por que foi em uma produção construir em primeiro lugar?Se não testou, não deixe-o, em seguida, você não tem que trabalhar fins-de-semana)

Para mim, eu comecei a insistir que a cada erro que eu encontrar e corrigir a ser expresso como um teste:

"Hmmm, isso não é certo..."
Encontre possível problema
Escrever um teste, mostram que o código de falha
Corrigir o problema
Mostrar que o novo código passa
Loop se o problema persistir

Eu tento fazer isso, mesmo enquanto grita coisas, e eu fico feito em aproximadamente o mesmo tempo, apenas uma parte do conjunto de teste, já em vigor.

(Eu não vivo em um comercial do ambiente de programação, e estou muitas vezes o único codificador de trabalho de um determinado projeto.)

Imagine que eu sou um mock programador, chamado...O Marco.Imagine eu ter formado a escola não muito tempo atrás, e nunca realmente tive que escrever os testes.Imagine eu trabalho em uma empresa que, realmente, não impor ou pede isso.OK?boa!Imagine, agora, que a empresa é a mudança para o uso de testes, e eles estão tentando me inline com isso.Vou dar um pouco sarcástico de reação para os itens mencionados até agora, como se eu não fizer alguma pesquisa sobre isso.

Vamos acabar com isso começou com o criador:

Mostrando que o design se torna mais simples.

Como pode escrever mais, fazer as coisas mais simples.Eu gostaria de ter agora para manter o controle sobre a obtenção de mais casos, e etc.Isso torna mais complicado se você me perguntar.Dê-me detalhes sólidos.

Mostrando previne defeitos.

Eu sei o que.É por isso que eles são chamados de testes.Meu código é bom, e eu marcada por problemas, por isso não estou a ver onde os testes de ajuda.

Tornando-se uma coisa de ego dizendo apenas maus programadores não.

Ohh, então você acha que eu sou um mau programador só porque eu não faço tanta utilizado o teste.Eu sou insultado e positivamente irritado com você.Eu preferiria ter assistência e apoio do que as palavras.

@Justin Padrão:No início do novo propect par junior cara com si mesmo ou a outro programador sênior.

Ohh, isso é tão importante que os recursos que serão gastos certificando-se de que eu vejo como as coisas são feitas, e tem alguns me ajudar sobre como as coisas são feitas.Isso é útil, e que eu só poderia começar a fazê-lo mais.

@Justin Padrão:Leia Os Testes De Unidade 101 apresentação por Kate Rhodes.

Ahh, que foi uma apresentação interessante, e me fez pensar sobre o teste.Ele martelou alguns pontos que devem ser considerados, e pode ter influenciado os meus pontos de vista um pouco.

Eu gostaria de ver mais artigos interessantes e outras ferramentas para me ajudar a ficar em linha com o pensamento esta é a maneira certa de fazer as coisas.

@Dominic Cooney:Passar algum tempo e compartilhar técnicas de teste.

Ahh, isso me ajuda a entender o que é esperado de mim tanto quanto técnicas, e coloca mais itens no meu saco de conhecimento, para que eu possa usar novamente.

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

Ter um ponto de pessoa (ou pessoas) para responder a pergunta, é útil, pode fazer-me mais provável que tentar.Bons exemplos são grandes, e ele me dá alguma coisa para o objetivo, e algo para olhar para referência.Livros que são relevantes para esta diretamente são a grande referência.

@Adam Hayle:Surpresa Revisão.

Dizer o que, que surgiu algo que eu sou completamente despreparados para.Eu me sinto desconfortável com isso, mas farei o meu melhor.Agora vou ficar com medo e levemente preocupado com esta chegando novamente, obrigado.No entanto, a tática do susto pode ter funcionado, mas ele tem um custo.No entanto, se nada funcionar, isso pode ser apenas o de empurrar o que é necessário.

@Rytmis:Os itens são apenas considerados feito quando eles têm de casos de teste.

Ohh, interessante.Eu vejo que eu realmente tenho de fazer isso agora, caso contrário, eu não sou de concluir qualquer coisa.Isso faz sentido.

@jmorris:Livrar-Se / Sacrifício.

brilhos, brilhos, brilhos - Há uma chance de que eu possa aprender, e com o apoio e a assistência, posso tornar-me muito importante e funcional das equipes.Esta é uma das minhas deficiências agora, mas não vai ser por muito tempo.No entanto, se eu só não entendo, eu entendo que eu vou.Eu acho que eu vou buscá-la.

No final, o apoio da minha equipe jogar com uma grande parte de tudo isso.Ter uma pessoa tomar o seu tempo para ajudar, e me começou em bons hábitos é sempre bem-vindo.Em seguida, depois de ter um bom apoio líquido seria ótimo.Ela sempre será apreciada ter alguém vir algumas vezes depois disso, e passar por cima de algumas código, para ver como tudo está fluindo, e não em uma revisão por si, mas mais como uma visita amigável.

O raciocínio, a Preparação, Ensino, acompanhamento, Apoio.

Tenho notado que um monte de programadores ver o valor de teste em um nível racional.Se você já ouviu coisas como "sim, eu sei que eu deveria testar isso, mas eu realmente preciso para conseguir este feito rapidamente", em seguida, você sabe o que quero dizer.No entanto, em um nível emocional, eles sentem que se conseguir que algo seja feito apenas quando eles estão escrevendo o código real.

O objetivo, então, deve ser, de alguma forma, fazê-los compreender que o teste é na verdade o apenas forma de medir quando algo é "feito", e assim dar-lhes a motivação intrínseca para escrever os testes.

Tenho medo de que muito mais difícil do que deveria ser, apesar de tudo.Você vai ouvir um monte de desculpas ao longo das linhas de "eu estou com pressa real, vou reescrever/refatorar isso mais tarde e, em seguida, adicione os testes" -- e, claro, o acompanhamento nunca acontece porque, surpreendentemente, eles são tão ocupado a próxima semana.

Aqui está o que eu faria:

Primeira vez..."nós vamos fazer esse projeto em conjunto.Eu vou fazer os testes e você está indo para escrever o código.Preste atenção como eu fazer os testes, pq é assim que fazemos as coisas por aqui e é isso que eu vou esperar de você."
Seguinte..."Você está pronto?Grande!Primeiro vamos olhar para os testes que estão a conduzir o seu desenvolvimento.Oh, não testa?Deixe-me saber quando isso é feito e nós vamos reagendar olhando para o seu código.Se você está precisando de ajuda para formular os testes deixe-me saber e eu vou ajudar você."

Como um programador júnior, eu ainda estou tentando adquirir o hábito de escrever testes.Obviamente, não é fácil para pegar os novos hábitos, mas pensando sobre o que iria fazer este trabalho para mim, eu tenho a +1 a comentários sobre as revisões de código e coaching/programação em par.

Ele também pode ser interessante sublinhar a longo prazo, a finalidade do teste:garantir que o que funcionou ontem ainda está trabalhando hoje, e na próxima semana, e no próximo mês.Digo apenas que, no deslizando as respostas eu não mencionado.

Fazendo as revisões de código (se você decidir fazer isso), certifique-se de que o seu jovem dev sabe que não se trata de colocá-lo para baixo, é sobre a fazendo com que o código melhor. Porque, dessa forma, a sua confiança é menos provável de ser danificado.E isso é importante.Por outro lado, então, é saber o quão pouco você sabe.

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

Editar:[Justin Padrão]

Não se colocar para baixo, o que você tem a dizer é muito bonito em direito.

No seu ponto de vista sobre as revisões de código:o que você vai encontrar é que não só o junior dev aprender no processo, assim como os revisores.Todos em uma revisão do código aprende se você torná-lo um processo colaborativo.

Francamente, se você está tendo para colocar que muito esforço em ficar-lhe para fazer algo, então você pode ter de chegar a termos com o pensamento de que ele pode não apenas ser um bom ajuste para a equipe, e pode precisar de ir.Agora, isso não significa necessariamente que demiti-lo...pode significar encontrar em outro lugar, na companhia de suas habilidades são mais adequados.Mas se não há nenhum outro lugar...você sabe o que fazer.

Eu estou supondo que ele também é bastante nova contratação (< 1 ano) e, provavelmente, recentemente, fora da escola...caso em que ele pode não estar acostumado a como as coisas funcionam em um ambiente corporativo.Coisas como o que a maioria de nós poderia começar afastado com a faculdade.

Se este for o caso, uma coisa que eu tenho encontrado funciona é ter uma espécie de "surpresa nova aluguer de revisão". Não importa se você nunca fez isso antes...ele não sabe que.Apenas sentar-lo e dizer-lhe o seu vai ir sobre o seu desempenho e lhe mostrar alguns números reais...tomar o seu normal revisão folha (você tem um processo de análise formal certo?) e altere o título, se você quer assim parece oficial e mostrar-lhe onde ele está.Se você mostrar a ele muito em um ambiente formal de que não está fazendo testes está afetando negativamente sua classificação de desempenho ao invés de apenas "lancinante" ele sobre isso, ele espera obter o ponto.Você tem que mostrar a ele que suas ações realmente irá afetá-lo ser ele a pagar o sábio ou o contrário.

Eu sei, você pode querer ficar longe de fazer isso porque ela não é oficial...mas eu acho que você está dentro razão para fazê-lo e que ele provavelmente vai ser muito mais barato do que ter de demiti-lo e contratar alguém novo.

Ele já está fazendo isso.Realmente.Ele não escrevê-la.Não está convencido?Vê-lo ir através do padrão de ciclo de desenvolvimento:

Escrever um pedaço de código
Compilá-lo
Correr para ver o que ele faz
Escreva o seguinte pedaço de código

Passo #3 é o teste.Ele já faz o teste, ele só faz isso manualmente.Pergunte-lhe esta pergunta:"Como você sabe que amanhã o código a partir de hoje ainda funciona?" Ele vai responder a:"É uma pequena quantidade de código!"

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

Quando ele ainda não tenho uma resposta, pergunte:"Como você gostaria que o seu programa de dizer quando uma alteração quebras de algo que funcionou ontem?"

Isso é o que automática, teste de unidade é toda sobre.

Como um programador júnior-me, eu pensei que a Identificação de revelar como foi quando eu me encontrei em uma situação semelhante à do seu desenvolvedor júnior.

Quando eu saí da faculdade, eu achei que ela tinha severamente onu preparou-me para lidar com o mundo real.Sim, eu sabia que algumas JAVA básico e alguma filosofia (não pergunte), mas que era sobre ele.Quando comecei o meu trabalho foi um pouco assustador, para dizer o mínimo.Deixe-me dizer-lhe que eu era, provavelmente, um dos maiores cowboys, eu iria hack juntos um pouco correção de bug / algoritmo sem comentários / testes / documentação e enviá-lo para fora da porta.

Eu tive sorte o suficiente para estar sob a supervisão de um tipo e muito paciente programador sênior.Felizmente para mim, ele decidiu sentar-se comigo e gastar de 1 a 2 semanas a passar-me muito hackeado togethor código.Ele teria de explicar de onde eu tinha ido errado, os melhores pontos de c e ponteiros (o menino fez que me confundir!).Conseguimos escrever um decente de classe/módulo em cerca de uma semana.Tudo o que posso dizer é que se o senior dev não tivesse investido tempo para me ajudar ao longo do caminho certo, eu provavelmente não teria durado muito tempo.

Felizmente, 2 anos para baixo da linha, espero que alguns dos meus colegas podem me considerar uma média de programadores.

Levar para casa, de pontos de

A maioria das Universidades são muito ruins em preparar os alunos para o mundo real
Emparelhado programação realmente me ajudou.Isso não quer dizer que ele vai ajudar a todos, mas ele trabalhou para mim.

Atribuí-los a projectos que não necessitam de "qualidade superior de código estável e" se essa é a sua preocupação e deixar que o jr.desenvolvedor de falhar.Peça-lhes que ser o único a 'vir o fim-de-semana' para corrigir seus erros.O almoço e um monte de falar sobre práticas de desenvolvimento de software (não as palestras, mas as discussões).Com o tempo, irá adquirir e desenvolver as melhores práticas para fazer as tarefas que lhes estão atribuídas.

Quem sabe, podem até mesmo vir acima com algo melhor do que as técnicas de sua equipe usa atualmente.

Se o programador júnior, ou qualquer pessoa, não se vê o valor em teste e, em seguida, será difícil levá-los a fazê-lo...e ponto final.

Eu teria feito o programador júnior sacrificar o seu fim-de-semana para corrigir o erro.Suas ações (ou a falta dele) não estão afetando diretamente com ele.Também, tornar evidente, que ele não vai ver o avanço e/ou aumentos de salário se ele não melhorar suas habilidades em teste.

No fim, mesmo com toda a sua ajuda, incentivo, orientação, ele não pode ser um ajuste para sua equipe, para deixá-lo ir e olhar para alguém que não obtê-lo.

Eu segunda RodeoClown comentário sobre o código de revisão a cada commit.Uma vez ele fez um justo poucas vezes em que ele vai ter o hábito de testar coisas.

Eu não sei se você precisar de bloco compromete-se, como que embora.No meu local de trabalho todo mundo tem livre comprometer-se a tudo, e todos os SVN commit mensagens (com diffs) são enviados para a equipe.

Nota:você realmente quer a o thunderbird colorido-diffs addon se você planeja fazer isso.

Meu chefe nem a mim mesmo (a 2 'senior' codificadores) vai acabar lendo sobre a comete, e se há qualquer coisa como "você esqueceu de adicionar testes de unidade" nós apenas mexa um e-mail ou ir e conversar com a pessoa, explicando por que eles precisavam de testes de unidade ou o que seja.Todo mundo é encorajado a ler o compromete-se também, como é uma ótima maneira de ver o que está acontecendo, mas o junior devs não comentar muito.

Você pode ajudar a encorajar as pessoas a adquirir o hábito de periodicamente dizendo coisas como "Ei, joão, você viu que cometem eu fiz esta manhã, eu encontrei este truque, onde você pode fazer blá blá que quer que seja, leia a consolidação e veja como ela funciona!"

NB:Temos 2 'senior' devs e 3 junior queridos.Isso pode não escala, ou você talvez precise ajustar o processo um pouco mais desenvolvedores.

Fazer a cobertura de código parte dos comentários.
Fazer "escrever um teste que expõe o erro" um pré-requisito para a fixação de um bug.
Exigem um certo nível de cobertura antes código pode ser verificada.
Encontrar um bom livro sobre test-driven development e usá-lo para mostrar como teste-primeiro pode velocidade de desenvolvimento.

Lotes de psicologia e útil "mentoring" técnicas, mas, em todos honestamente, isso só se resume a "escrever os testes, se você quiser, ainda tem um emprego, amanhã."

Você pode sofá de termos tudo o que você acha que são apropriados, áspero ou macio, não importa.Mas o fato é que os programadores não são pagos apenas jogar juntos código e check-in -- eles são pagos para cuidado de colocar junto o código, em seguida, colocar juntos os testes, depois teste o seu código e, em SEGUIDA, verifique toda a coisa.(Pelo menos é o que parece, a partir da sua descrição.)

Portanto, se alguém vai se recusar a fazer o seu trabalho, explicar-lhes que eles podem ficar em casa, amanhã, e você vai contratar alguém que IRÁ fazer o trabalho.

Novamente, você pode fazer tudo isso com cuidado, se você acha que é necessário, mas muitas pessoas só precisam de um grande disco rígido tapa de A Vida No Mundo Real, e você estaria fazendo um favor dando a eles.

Boa sorte.

Alterar a sua descrição do trabalho por um tempo para apenas ser escrita de testes e manutenção de testes.Ouvi dizer que muitas empresas fazem isso para novas pessoas inexperientes, por um tempo, quando eles começam.

Além disso, o problema de um desafio, enquanto ele está no papel:Escrever os testes que será uma) falha no código atual a) cumprir os requisitos do software.Esperemos que ele vai causar-lhe para criar uma sólida e completa (testes de melhorar o projeto) e torná-lo melhor na escrita de testes para quando ele re-integra o núcleo de desenvolvimento.

editar> realizar os requisitos do software, o que significa que ele não é apenas escrever testes, propositalmente, para quebrar o código quando o código nunca se destina ou necessária para tomar o caso de teste em conta.

Se o seu colega carece de experiência de escrever testes talvez ele ou ela está a ter dificuldade de teste além de situações simples, e que está se manifestando como inadequada de testes.Aqui está o que eu gostaria de experimentar:

Passar algum tempo e compartilhar técnicas de testes, como o de injeção de dependência, olhando para casos extremos, e assim por diante com seu colega.
Oferta para responder a perguntas sobre o teste.
Fazer as revisões de código de testes por um tempo.Pergunte ao seu colega para revisar as alterações de vocês que são exemplares de bons testes.Descubra os seus comentários para ver se eles são realmente de ler e compreender o código de teste.
Se há livros que se encaixam muito bem com a sua equipa de testes da filosofia dê-lhe uma cópia.Ele pode ajudar se o seu código de revisão de comentários ou discussões referência o livro, de modo que ele ou ela tem uma thread para pegar e seguir.

Eu não especialmente enfatizar a vergonha/culpa fator.Vale ressaltar que é um teste amplamente adotado, boas práticas e de que a escrita e a manutenção de boas testes é uma cortesia profissional para seus companheiros de equipe não precisa de passar os seus fins-de-semana no trabalho, mas eu não iria insistir nesses pontos.

Se você realmente precisa "ficar duro", em seguida, instituto imparcial sistema;ninguém gosta de se sentir como eles estão sendo apontados.Por exemplo, a sua equipe poderá requerer código para manter um certo nível de cobertura de teste (capaz de ser gamed, mas pelo menos capaz de ser automatizada);exigir novo código para fazer testes;exigir que os revisores em consideração a qualidade dos testes ao fazer as revisões de código;e assim por diante.Instituindo-se de que o sistema deve vir a partir do consenso de equipe.Se você moderar o debate com cuidado você pode descobrir outros motivos subjacentes de seu colega de testes não é o que você espera.

É o seu Mentor responsabilidade de Ensiná-lo.O quão bem você está ensinando-lhe COMO fazer o teste.Você está a programação em par com ele?O Junior mais do que provável que não sabe COMO configurar um bom teste para a xyz.

Como Júnior, freshout da escola, ele conhece muitos Conceitos.Alguns técnica.Alguma experiência.Mas no final, todos Júnior é POTENCIAL.Quase todos os recursos que eles trabalham, haverá algo novo que nunca foi feito antes.Se o Junior pode ter feito um simples Estado padrão para um projeto em sala de aula, abrindo e fechando "portas", mas nunca um mundo real aplicação dos padrões.

Ele/ela só vai ser tão bom como o quão bem você ensinar.Se eles foram capazes de "Just get it" você acha que poderia ter levado um Júnior posição, em primeiro lugar?

Na minha experiência Juniores são contratados e deu quase a mesma responsabilidade como Idosos, mas são apenas paga menos e, em seguida, ignorado quando eles começam a vacilar.Perdoe-me se eu parecer amargo, é porque eu estou.

@ jsmorris

Uma vez eu tinha o desenvolvedor sênior e "arquiteto" repreender-me e um testador(foi o meu primeiro trabalho fora da faculdade) no e-mail, para não ficar a tarde e acabamento tão "fácil" tarefa na noite anterior.Nós tinha sido para ele todos os dias e chamou ele fecha às 7 da noite, eu tinha sido goleada desde as 11h, antes do almoço, que dia e tinha importunado cada membro de nossa equipe para ajudar a pelo menos duas vezes.

Eu respondi e "cc", a equipe com:"Eu já fui decepcionado com você por um mês agora.Eu nunca obter ajuda da equipe.Eu vou estar no café do outro lado da rua se você precisar de mim.Me desculpe, eu não conseguia depurar a 12 de parâmetro, 800 método de linha que quase tudo é dependente."

Depois de se refrescar no café por uma hora, fui no escritório, pegou minha porcaria e esquerda.Depois de alguns dias eles me ligou perguntando se eu estava chegando, eu disse que eu iria, mas eu tinha uma entrevista, talvez amanhã.

"Então, o sair, então?"

No seu repositório de código-fonte :use ganchos antes de cada compromete-se (pre-commit, o gancho para o SVN, por exemplo)

Nesse gancho, verificar a existência de pelo menos um caso de uso para cada método.Usar uma convenção para o teste de unidade da organização que você pode aplicar facilmente através de um pré-compromisso de gancho.

Em um servidor de integração compilar tudo e confira regularely a cobertura de teste através de um teste ferramenta de cobertura.Se o teste de cobertura não é 100% um código, bloquear qualquer confirmação de que o desenvolvedor.Ele deve enviar-lhe que o caso de teste que cobre 100% do código.

Apenas verificações automáticas podem escala bem em um projeto.Você pode verificar tudo com a mão.

O desenvolvedor deve ter um significa para verificar se a sua casos de teste cobre 100% do código.Dessa forma, se ele não se comprometer 100% testado código, é sua própria culpa, e não um "oops, desculpe, eu esqueci" culpa".

Lembre-se :As pessoas nunca fazem o que você espera, eles sempre fazem o que você inspecionar.

Primeiro, como a maioria dos inquiridos aqui de salientar, se o cara não vê o valor de teste, não há muito que você possa fazer sobre isso, e você já apontou que você não pode demitir o cara.No entanto, a falha não é uma opção aqui, de modo que sobre as poucas coisas que você pode fazer?

Se a sua organização for grande o suficiente para ter mais de 6 desenvolvedores, eu recomendo fortemente que ter um departamento de Garantia de Qualidade (mesmo se apenas uma pessoa para iniciar).Idealmente, você deve ter uma proporção de 1 testador para 3-5 desenvolvedores.A coisa sobre os programadores é ...eles são programadores, não testadores.Eu ainda tenho que entrevistar um programador que tem sido ensinado formalmente adequada QA técnicas.

A maioria das organizações fazer a falha fatal de atribuir a testes de funções para o novo aluguel, a pessoa com o MÍNIMO de exposição para o seu código -- idealmente, os desenvolvedores sênior deve ser movido para o controle de papel como eles têm experiência no código, e (espero) ter desenvolvido um sexto sentido para o código de cheiros e pontos de falha que podem surgir.

Além disso, o programador que fez o erro provavelmente não vai encontrar o defeito, porque geralmente não é um erro de sintaxe (aqueles apanhados na compilação), mas um erro de lógica-e a mesma lógica é no trabalho, quando eles escrevem o teste como quando escrevem o código.Não ter a pessoa que desenvolveu o código de teste que o código-que vai encontrar menos erros do que qualquer outra pessoa faria.

No seu caso, se você pode pagar a redirecionado esforço de trabalho, fazer essa cara nova o primeiro membro de sua equipe de controle de qualidade.Levá-lo para ler "Teste de Software No Mundo Real:Melhorar O Processo", porque ele obviamente vai precisar de algum tipo de treinamento em sua nova função.Se ele não gosta, ele vai sair e o problema ainda está resolvido.

Um pouco menos vingativa abordagem seria deixar esta pessoa a fazer o que eles são bons (eu estou supondo que essa pessoa tem contratado porque eles, na verdade, são competentes para a parte de programação do trabalho) , e contratar um testador ou dois para fazer o teste (Universidade muitas vezes, os alunos têm aulas práticas ou "co-op" termos, gostaria de exposição, e são baratos)

Nota:Eventualmente, você vai querer a equipe de controle de qualidade de relatório para um QA diretor, ou pelo menos não para um desenvolvedor de software manager, porque tendo a equipe de controle de qualidade relatório para o gerente que o principal objetivo é obter o produto feito de um conflito de interesses.

Se a sua organização é menor que 6, ou você não pode sair com a criação de uma nova equipe, eu recomendo emparelhado programação (PP).Eu não sou um total de converter de todos os extremos, técnicas de programação, mas eu, definitivamente, um crente em emparelhado programação.No entanto, ambos os membros do par equipe de programação tem que ser dedicado, ou ele simplesmente não funciona.Eles têm que seguir duas regras:o inspector tem de compreender totalmente o que está sendo codificado no ecrã ou ele tem que pedir o codificador para explicá-lo;o codificador pode apenas código que ele pode explicar -- não "você vai ver" ou "confie em mim" ou de mão, acenando será tolerado.

Eu só recomendo PP se o seu time é capaz de ele, porque, como teste, nenhuma quantidade de fãs ou ameaçador vai convencer um casal de ego-preenchidos os introvertidos a trabalhar juntos se não se sentir confortável para fazer isso.No entanto, acho que entre a escolha de escrever detalhado de especificações funcionais e fazer as revisões de código vs.emparelhado programação, PP, geralmente ganha.

Se o PP não é para você, em seguida, TDD é a sua melhor aposta, mas apenas se sua tomada literalmente.Desenvolvimento Orientado a testes significa que você escrever os testes PRIMEIRO, execute os testes para provar que eles realmente fazem falhar, em seguida, escrever o código mais simples para fazê-lo funcionar.O trade-off é agora que você (deveria) ter uma coleção de milhares de testes, que também é de código, e é tão provável como código de produção para conter bugs.Eu vou ser honesto, eu não sou um grande fã de TDD, principalmente devido a este motivo, mas funciona para muitos desenvolvedores que preferem escrever scripts de teste de caso de teste documentos -- alguns testes é melhor do que nenhum.Casal TDD com o PP para uma probabilidade de cobertura de teste e menos erros no script.

Se tudo mais falhar, de ter os programadores de equivalência de um juro jar-cada vez que o programador quebras de o construir, eles têm que colocar r $20, $50, $100 (o que for moderadamente dolorosas para seus funcionários) em um frasco que vai para o seu favorito (registrado!) caridade.Até que eles pagam até, fugir deles :)

Todas as piadas de lado, a melhor maneira de obter o seu programador para escrever testes é não deixá-lo do programa.Se você quer um programador, contratar um programador -- Se você quiser testes, contratar um testador.Eu comecei como programador júnior, há 12 anos fazendo o teste, e ele virou-se em minha carreira, e eu não trocaria isso por nada.Um sólido QA departamento que está devidamente alimentado e dado o poder e o mandato para melhorar o software é tão importante quanto o que os desenvolvedores escrever o software, em primeiro lugar.

Este pode ser um pouco cruel, mas a maneira como você descreveria a situação parece que você precisa de fogo esse cara.Ou pelo menos torná-lo claro:recusando-se a seguir casa de práticas de desenvolvimento (incluindo a escrita de testes) e verificação de buggy e de código que outras pessoas têm para limpar acabará por levá-lo demitido.

A principal razão engenheiros junior/programadores não se levar muito tempo para projetar e executar scripts de teste, é porque a maioria dos CS certificações não fortemente exigir isso, para que outras áreas de engenharia de são abordados mais na faculdade programas, tais como o design patters.

Na minha experiência, a melhor forma para obter o junior profissionais no hábito, é torná-lo parte do processo explicitamente.Que é, ao estimar o tempo de uma iteração deve tomar, o tempo de criação, gravação e/ou executar os casos devem ser incorporados a esta estimativa de tempo.

Finalmente, analisando o script de teste de design deve ser parte de uma revisão do projeto, e o código devem ser analisados na revisão de código.Isso faz com que o programador responsável por fazer o teste apropriado de cada linha de código que ele/ela escreve, e o engenheiro chefe e colegas de responsabilidade de fornecer feedback e orientações sobre o código e teste escrito.

Com base no seu comentário, "Mostrando que o design se torna mais simples" eu estou supondo que vocês prática de TDD.Fazendo uma revisão do código, depois o fato é que não vai funcionar.A coisa toda sobre TDD é que é um projeto e não uma filosofia de testes.Se ele não escrever testes, como parte do projeto, você não vai ter um monte de benefícios da escrita de testes após o fato, especialmente a partir de um desenvolvedor júnior.Ele vai acabar perdendo um monte de casos de canto e de seu código ainda serão de baixa qualidade.

Sua melhor aposta é a de ter um muito paciente desenvolvedor sênior para sentar-se com ele e fazer alguma programação em par.E apenas mantê-la até que ele aprende.Ou não aprender, caso em que você precisa para voltar a atribuir-lhe uma tarefa que ele é mais adequado, porque você só vai acabar frustrando o seu real desenvolvedores.

Nem todos tem o mesmo nível de talento e/ou motivação.As equipes de desenvolvimento, mesmo ágeis, são constituídas de pessoas sobre a "a-Team" e as pessoas "Equipe B".Um-os membros da Equipe são o que um arquiteto de solução, escrever todos os não-trivial de produção de código, e se comunicar com os proprietários da empresa - todo o trabalho que requer pensar fora da caixa.O B-Equipe a lidar com coisas como o gerenciamento de configuração, a escrita de scripts, fixação coxo bugs, e fazendo manutenção de obra - todo o trabalho que tem procedimentos rigorosos que têm pequenas consequências para o fracasso.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow