Como verifico se meus testes não foram removidos por outros desenvolvedores?

8

Acabei de encontrar um problema interessante de codificação colaborativa no trabalho.

Eu escrevi alguns testes de unidade / funcional / integração e implementei novas funcionalidades no aplicativo que tem ~ 20 desenvolvedores trabalhando nele. Todos os testes foram aprovados e eu verifiquei o código. No dia seguinte, atualizei meu projeto e notei (por acaso) que alguns dos meus métodos de teste foram excluídos por outros desenvolvedores (mesclando problemas no final). O novo código do aplicativo não foi tocado.

Como posso detectar esse problema automaticamente? Quero dizer, escrevo testes para verificar automaticamente se meu código ainda funciona (ou não foi excluído). Como faço o mesmo para testes?

Estamos usando Java, JUnit, Selenium, SVN e Hudson CI, se isso importa.

— parxier
fonte

1

Eu nem tenho certeza de como você "acidentalmente" excluiria partes inteiras de código se você estivesse realmente fazendo uma coisa adequada de puxar -> mesclar -> confirmar.

— Anon.

@ Anon também tenho certeza, ele diz que estava com pressa e precisava confirmar seu código rapidamente, então não prestou muita atenção à fusão de coisas ou coisas. : - / De qualquer forma, ainda quero detectar esses problemas automaticamente no nível do IC.

— parxier

10

E a pessoa "que estava com pressa" pode precisar de uma conversa tranqüila de um gerente, esse comportamento é preguiçoso e não deve ser aceitável.

— quickly_now

1

Só posso imaginar que isso seria possível se as pessoas estivessem verificando grandes mudanças com muitos arquivos modificados por muito tempo. Você normalmente não deve ter fusões enormes, onde existe a possibilidade de o código ser "perdido" ... isso parece a fonte real do problema para mim.

— 10246 Dean Dean Harding

1

É por isso que um desenvolvedor individual nunca deve ter permissão para mesclar com o tronco em VCSs centralizados. Os desenvolvedores preguiçosos tendem a espancar as coisas de outras pessoas (eu mesmo fui culpado).

— Chris K

4

Não estou familiarizado com o Hudson para IC, mas minha ferramenta de IC também pode calcular a cobertura de código. Se você puder escrever um processo que o notificará quando a cobertura do código diminuir, isso seria um bom indicador de que um teste foi removido. Também informa se o novo código foi adicionado sem testes. Não é o que você estava perguntando, mas é bom saber.

— Marcie
fonte

3

Eu estava prestes a mencionar esse ponto em um comentário à resposta de Tim: seu percentual de cobertura de código nunca deve diminuir.

— Frank Shearar

Bom ângulo em uma métrica!

Que ferramenta é essa, por acaso?

— Chris K

@ Chris, usamos o TFS + TeamBuild, que eu configurei para calcular a cobertura do código em cada Build.

— Marcie

Não vai funcionar nesse projeto em particular, porque a cobertura dos testes é bastante baixa no momento, então tenho que tentar a ideia de Tim. Mas você me deu uma boa solução e acho que é a melhor resposta para minha pergunta.

— parxier

12

As isenções de responsabilidade padrão se aplicam: estamos criando uma solução de engenharia para um problema social. No entanto, esse é um problema de higiene do projeto, por isso é um pouco como dizer que os banheiros são uma solução de engenharia para um problema social.

Tenha um trabalho entregue o feed RSS do Hudson. Conte o número de testes no relatório Hudson. Se diminuir, toque um alarme. Tenha um auto-da-fe 'quando o alarme tocar.

O culpado do commit pode ser identificado e punido. Seu problema vai desaparecer.

Você pode criar outros problemas como resultado desta solução. Se a tontura persistir, consulte o seu médico.

— Tim Williscroft
fonte

1

+1: "estamos criando uma solução de engenharia para um problema social". Esse deve ser o fim da resposta. O restante da resposta é menos valioso do que essa afirmação.

— S.Lott

2

@ Slott sim, mas se você tornar mais fácil fazer a coisa certa, isso será feito. Usamos um email automático para toda a equipe, que foi acionado ao interromper a compilação. Funciona; você toma mais cuidado. Pessoalmente, duvido da utilidade de tentar resolver esse problema social. Se você honestamente acha que excluir testes é bom, a cultura da empresa é contrária à qualidade.

— Tim Timisiscroft

Uau, sou portuguesa e não fazia ideia do que é um auto-da-fé.

— R. Martinho Fernandes

A contagem de testes pode diminuir por razões válidas: uma refatoração pode remover uma classe e todos os seus testes de unidade. No entanto, ainda vale a pena descobrir por que a contagem de testes caiu.

— 31811 Frank Shearar

@Frank Suponho que importaria se com que freqüência a contagem de testes caísse por razões válidas em comparação com as inválidas. Se a maioria dos motivos são válidos, o alarme será ignorado após um pouco e se tornará inútil. Se a maioria é inválida, pode ser boa. Quantas vezes isso acontece? E, na verdade, @parxier, se isso aconteceu apenas uma vez que você soube, você poderia estar reagindo exageradamente?

— James

2

Abordagem organizacional

Tenha uma política em vigor que exija que a pessoa exclua os testes converse com o criador do teste. Normalmente, você excluiria testes apenas ao depreciar alguma funcionalidade que está sendo testada, e isso não acontece com muita frequência.

Abordagem técnica

Essa é mais a abordagem do controle, mas você pode ter um teste separado, que verifica o código-fonte quanto à presença de todos os testes que deseja verificar. Possivelmente você também pode interagir com o Hudson e obter a lista de testes executados.

— Arte
fonte

O material foi excluído durante uma mesclagem. Talvez por acidente, talvez por preguiça. A política não vai fazer muito além de mais "tu" da administração, que todos irão ignorar. Um público queimando e açoitando pode receber alguma atenção, no entanto. / sarcoff

— rapid_now

2

@quickly_now: "O material foi excluído durante uma mesclagem". Isso deve ser uma ofensa. Qualquer organização que permita esse comportamento realmente precisa remover muitas pessoas e substituí-las por pessoas que se esforçam para fazer algo sensato em vez do mal.

— S.Lott 4/02

Acidente - você pode perdoá-lo pela primeira vez. Preguiça ou ofensa maliciosa - sim - de saque.

— quickly_now

Seria difícil manter essa classe de teste atualizada, mas é uma ideia interessante, obrigado.

— parxier

0

Semelhante à resposta de Art ..

Comentários Comece usando o comentário bem. Para cada método; não esqueça de colocar a entrada e saída esperadas, uma breve descrição para funções mais complexas e seu nome.

Diretrizes Mas isso realmente destaca que há uma necessidade de mais comunicação entre o desenvolvedor. equipe. Deve haver diretrizes para trabalhar em conjunto ... ou pelo menos conversar com seu proj. gerente e peça que ele esclareça isso entre a equipe.

Uso adequado do SVN Você também pode escrever suas classes e métodos e rastreá-los. Também enquanto estiver usando o SVN, espero sinceramente que essas exclusões sejam rastreadas como alterações, anotadas separadamente e com BOAS razões.

Antes de escrever um programa especial, você também pode comparar o diff. arquivos no SVN para rastrear alterações nos seus métodos.

— Ross
fonte

0

O mesmo poderia acontecer com o código real e você não saberá até perceber que sua alteração não existe mais.

Dito isto, é difícil identificar o código que está sendo removido como algo ruim, pois muitas vezes você remove manualmente o código / recursos, etc.

— ozz
fonte

Quando o código é excluído, os testes são interrompidos. Quando os testes são excluídos, nada é interrompido.

— parxier