Como crio um ambiente em que a correção de testes é vista como uma prioridade?

Sou engenheiro de software em uma empresa de médio porte. Temos uma plataforma de teste bastante robusta em execução no TeamCity. Ele realiza testes de unidade em cada check-in e executa um teste de unidade diário / BVT.

O problema é - nós temos muitos testes de unidade quebrados.

Freqüentemente, exponho a inutilidade dos testes de unidade, se eles estão constantemente quebrando e sem manutenção. Ser incapaz de ver se uma alteração causou uma regressão remove a maior parte do valor de uma plataforma de teste de unidade.

Eu gostaria de plantar uma semente que crie uma cultura de bons hábitos - corrigindo testes quando quebrados, vendo-os valiosos, priorizando a fixação de testes junto com outros trabalhos.

Eu tentei suborno (assados!), Simplesmente perguntando e falando com os líderes da equipe. Todo mundo diz que é uma boa ideia, mas vejo ser o único a fazer alguma coisa a respeito.

Qual é a melhor maneira de começar a incentivar outras pessoas a corrigir seus testes e priorizar a correção de testes em seus sprints?

Se houver uma maneira menos subjetiva de fazer isso, ficarei feliz em aceitar algumas dicas.

— Codeman
fonte

Nerf arma automática que visa o cara quebrar a construir ...

— catraca aberração

Nós realmente temos uma arma nerf automática ... mas a construção não está quebrado, apenas os testes de unidade :)

— Codeman

Quebrar os testes de unidade deve implicar na quebra da compilação. ;)

— Jeroen Vannevel 14/11

@ Observação: o buy-in é importante, mas você não pode obter buy-in para resolver um problema até que as pessoas estejam cientes do problema. Nesse caso, o buy-in precisa apenas inicialmente dos líderes e gerentes da equipe. A adesão do desenvolvedor pode ocorrer mais tarde e geralmente ocorrerá naturalmente quando o sistema de compilação tiver sido configurado para fazer com que os desenvolvedores individuais paguem por seus próprios erros.

— Aaronaught

Se os donuts falharem, você está brindando. :-)

— Ross Patterson

Respostas:

Faça com que seja impossível realmente liberar qualquer coisa sem corrigir os testes.

Falha na construção se algum teste falhar.
Falha na construção se algum teste for ignorado.
Falha na compilação se a cobertura do teste ficar abaixo de um determinado nível (para que as pessoas não possam simplesmente excluir os testes para contorná-la).
Use o servidor de IC para fazer suas compilações de release e permita apenas que as compilações da queda de compilação do servidor sejam promovidas para UAT / staging / production / o que for.

O fato é que, se sua compilação for interrompida por mais de 15 minutos por vez (e isso inclui testes com falha), você não estará fazendo a integração contínua .

A "opção nuclear" é fazer com que o servidor de controle de origem recuse as confirmações / verificações de qualquer usuário que não seja aquele que quebrou a compilação. Obviamente, um administrador precisa substituí-lo temporariamente se a pessoa sair de férias - mas, se todos souberem que toda a equipe está ferrada até que eles façam seus testes, eles resolverão isso rapidamente.

Uma boa política (que é ainda melhor quando automatizada) é reverter a fonte para a última confirmação estável conhecida após 15 minutos de falha na compilação. Em outras palavras, se você não pode corrigi-lo ou não sabe o que causou a compilação ou o teste, revertê-lo e trabalhar localmente até que seja resolvido - nunca faça outros desenvolvedores mexerem o polegar enquanto você se afasta. problema que eles não se importam.

PS Se você já tiver muitos testes com falha, poderá usar um "limite à direita" no IC. Configure-o para que a construção falhe apenas se houver mais falhas de teste do que na última vez. Isso, juntamente com uma regra de cobertura, forçará os desenvolvedores a melhorar a situação do teste, se quiserem continuar trabalhando.

PPS: Eu sei que isso pode parecer draconiano para alguns, mas tudo depende da sua cultura. Se você chegar a um ponto em que as pessoas simplesmente não deixam a compilação quebrada ou os testes falham (minha equipe quase nunca o faz, embora eu precise lembrá-los ocasionalmente), não é necessário continuar com o conjunto mais estrito de regras. Embora IMO, você sempre deve falhar na compilação em um teste de unidade quebrado. Os testes de integração / navegador podem falhar às vezes.

— Aaronaught
fonte

Embora todas as suas dicas técnicas sejam úteis, acho que a parte mais valiosa da sua resposta é que “é toda a sua cultura”, porque mais do que um problema de disciplina, é um problema de utilidade percebida do teste. Eu prefiro colocá-lo à frente do que em um PPS

— user40989

@ user40989: eu ouço você. Cultura é algo que você precisa cultivar. Se você deseja que as pessoas entendam a importância dos testes, às vezes é necessário fazê-lo para que as pessoas não possam ignorá-los. Quando as pessoas se acostumarem a um alto nível de cobertura de código e testes verdes, elas não desejarão voltar e, então, seus próprios desenvolvedores a aplicarão a novos recrutas. Bem, espero. Um líder de equipe anal-retentivo e / ou cria mestre e / ou gerente ajuda. :)

— Aaronaught 14/11

FWIW: Todo o nosso processo de lançamento agora está automatizado e as pessoas não pensariam em fazer testes quebrados. O líder da equipe faz uma mesclagem com o mestre, inicia uma compilação de liberação e envia uma solicitação de promoção aos administradores do sistema que literalmente pressionam um botão para implantar a partir dos artefatos de compilação e executar testes automatizados de navegador e API. Nunca ninguém reclama desse processo, porque ele economiza tempo - costumávamos passar duas semanas se preocupando com um lançamento, agora é basicamente uma onda de mão. É isso que quero dizer com o cultivo da cultura - todo mundo sabe que os 2 minutos extras para fazer um teste economizarão 2 horas depois.

— Aaronaught

Testes de unidades que falham não são o problema. Eles são um sintoma .

O verdadeiro problema está na cultura. Você precisa pisar suavemente: aqui estão dragões . Você não pode mudar a cultura sozinho, e ser a roda estridente fará com que você seja um pária. Literalmente.

Sugiro que, se você tentar encontrar uma pessoa sênior para defender a causa e liderar o caminho. Se isso falhar, tente aumentá-lo em uma reunião geral de desenvolvedores, sem apontar o dedo ou chamar nomes. Outra alternativa é se responsabilizar por fazer um trabalho adequado: basta fazer mais alguns testes sempre que fizer um check-in. Mantenha um gráfico na parede mostrando quantos testes falham ao longo do tempo. Outros verão: talvez eles optem por participar.

Não há uma resposta fácil.

— andy256
fonte

Ser a roda estridente me fez liderar a equipe. Talvez houvesse algo errado com o seu chiado? Com toda a seriedade, porém, isso fala de um problema cultural muito diferente , não com a equipe de desenvolvimento, mas com a gerência da empresa. Se a resposta da gerência a um fogo ardente é colocar óculos de sol, basta dar o fora dali. Mas se você é realmente uma loja de desenvolvimento , em oposição a um departamento de TI corporativo que produz software de um centro de custos, é bem provável que os gerentes se preocupem com coisas como a frequência e a segurança que você pode lançar no mercado.

— Aaronaught