Qual é a maneira mais convincente para exigir o teste de unidade formalizada?

https://stackoverflow.com/questions/120460

02-07-2019
|

Pergunta

Isso certamente pressupõe que o teste de unidade é uma coisa boa. Nossos projetos têm algum nível de teste de unidade, mas é inconsistente no melhor.

Quais são as formas mais convincentes que você usou ou tiveram usados ??com você para convencer a todos que o teste de unidade formalizada é uma coisa boa e que tornando-se necessário é realmente no melhor interesse dos projectos 'largeish' que trabalham em . Eu não sou um desenvolvedor, mas eu estou em Quality Assurance e gostaria de melhorar a qualidade do trabalho entregue para garantir que ele está pronto para teste.

Por testes de unidade formalizados, eu estou simplesmente falando sobre

A identificação dos testes de unidade a ser escrito
Identificar os dados de teste (ou descrever)
Escrevendo estes testes
Como acompanhar estes testes (e re-utilizando, conforme necessário)
disponibilização dos resultados

Solução 13

Assim, dois anos depois eu fiz esta pergunta, eu acho que uma resposta inesperada foi que movendo para um novo SDLC era o que era necessário. Há cinco anos, nós estabelecemos nossa primeira SDLC formal. Melhorou nossa situação, mas deixou de fora algumas coisas importantes, como automação. Estamos agora no processo de estabelecer uma nova SDLC (sob nova gestão) em que um dos inquilinos é a automação. Não apenas automatizada testes de unidade, mas automatizado testes funcionais.

Eu acho que a lição é que eu estava pensando muito pequeno. Se você estiver indo para mudar o modo de criar software, ir 'porco inteiro' e fazer uma mudança drástica em vez de propor uma mudança incremental, se você não está acostumado a isso.

Outras dicas

Uma maneira muito convincente é fazer formalizada teste de unidade mesmo, independentemente do que a sua equipe / empresa faz. Isso pode levar algum esforço extra do seu lado, especialmente se você não tem experiência com esse tipo de prática.

Quando você pode, então, mostrar o seu código é melhor e você está sendo mais produtivo do que os seus colegas desenvolvedores, eles vão querer saber o porquê. Em seguida, alimentá-los seus métodos de teste de unidade favoritas.

Uma vez que você convenceu seus desenvolvedores companheiros, convencer a administração em conjunto.

Eu uso Maven com o Surefire e plugins cobertura para toda a minha constrói. Os casos de testes reais são criadas com JUnit , DbUnit e EasyMock .

Identificação de testes de unidade Eu tento seguir Test Driven Development, mas para ser honesto eu normalmente só fazer isso por um punhado de casos de teste e, em seguida, voltar e criar testes para os casos de ponta e de exceção mais tarde.

Identificar dados de teste DbUnit é ótimo para os dados de teste de carga para os testes de unidade.

Casos Escrita Teste Eu uso JUnit para criar os casos de teste. Tento casos de teste de gravação auto documentando mas vai usar Javadocs de comentar algo que não é óbvio.

Rastreamento e disponibilização dos resultados I integrar a unidade de teste para o meu ciclo compilação Maven usando o plug-in e infalível eu usar o plug-in Corbertura para medir a cobertura obtida por esses testes. Eu sempre gerar e publicar um website, incluindo os relatórios Surefire e cobertura como parte da minha compilação diária para que eu possa ver o que os testes falharam / passada.

O evento, que me convenceu foi quando conseguimos a regredir um erro três vezes, em três lançamentos consecutivos. Depois que eu percebi o quanto mais produtivo eu era como um programador quando eu não estava constantemente corrigir erros triviais depois de terem ido para o cliente, e eu poderia ter um sentimento aconchegante que o código colegas faria o que eles alegaram que seria, eu me tornei um convertido.

De volta ao dia que eu fiz desenvolvimento Cobol em Mainframes Fizemos isso religiosamente nas diversas empresas em que trabalhei e ela foi aceita como a forma como você fez as coisas porque o ambiente aplicadas lo. Acho que foi um esquema muito típico para a época e talvez algumas das razões pode ser aplicável a você: -

Como a maioria dos ambientes de mainframe tivemos três reinos, desenvolvimento, garantia de qualidade e produção. Programadores desenvolvidas em desenvolvimento e unidade testada lá, e uma vez que fora assinado e foram felizes a unidade foi migrado para o ambiente de QA (com os documentos e resultados de testes) onde foi sistema testado pela equipe de QA dedicado. O desenvolvimento da migração QA foi um passo formal que aconteceu durante a noite. Uma vez QA'ed o código foi migrado para Produção - e tivemos muito poucos erros

A motivação para obter a unidade de teste feito e direita era que se você não e um bug foi encontrado pela equipe de QA era óbvio que você não tinha feito o trabalho. Consequentemente sua reputação dependia de como rigorosa você era. Claro que a maioria das pessoas iria acabar com o erro ocasional, mas codificadores que produziram código testado sólido o tempo todo em breve tem uma reputação estrela e aqueles que produziram código de buggy foi notado também. O impulso seria sempre para o seu jogo, e, consequentemente, a cultura produzida era um que empurrado para erro de código livre entregues primeira vez.

Extraindo pertinentes pontos -

Coder reputação amarrado com entrega de erro de código livre testado
significativa sobrecarga associada com o movimento de código testado unidade para o próximo nível, então a motivação para não repetir isso e obtê-lo direito primeira vez.
sistema de testes realizados por pessoas diferentes para o teste de unidade -. Idealmente uma equipe diferente

Tenho certeza que seu ambiente será diferente, mas os princípios podem ser traduzível.

Às vezes, por exemplo, é o melhor caminho. Também acho que lembrar as pessoas de que certas coisas simplesmente não acontecem quando as coisas estão sob teste. Da próxima vez que alguém lhe pede para escrever algo, fazê-lo com os testes independentemente. Eventualmente seus pares vai ficar com ciúmes da facilidade com que você pode alterar o código e saber que ele ainda funciona.

Como para a gestão é preciso enfatizar quanto tempo é desperdiçado devido à explosão nuclear que ocorre quando você precisa fazer uma mudança de base de código X que is not sob teste.

Muitos desenvolvedores não percebem o quanto eles refatorar sem garantir que eles estão preservando o comportamento em todo o sistema. Para mim, este é o maior benefício para o teste de unidade e TDD na minha opinião.

requisitos Software mudança
Software muda para atender às necessidades

A única certeza é a mudança. Alterar código que não está em teste requer o desenvolvedor estar ciente de todos os efeitos colaterais comportamentais possível. A realidade é que os codificadores que pensam que podem ler em cada permutação, fá-lo por uma dor processo de tentativa e erro apostar até breaks nada, obviamente. Neste ponto, eles check-in.

O programador pragmático reconhece que ele / ela não é perfeito e onisciente, e que os testes são como uma rede de segurança que lhes permite andar na corda bamba refatoração rápido e seguro.

Como para quando teste de escrita no código greenfield, eu teria que defendem tanto quanto possível. Passe o tempo que define o comportamentos que você quer fora de seus testes de sistema e escrever inicialmente para expressar essas construções de nível superior. Os testes de unidade pode vir como pensamentos cristalizar.

Espero que isso ajude.

Educação e / ou certificação.

Dê aos seus membros da equipe um treinamento formal na área de teste - talvez com exame de certificação (dependendo membros de sua equipe e sua própria atitude em relação à certificação). Você vai tomar o teste para um nível mais elevado dessa maneira, e os membros da equipe vai ser mais propensos a tomar uma atitude profissional para testes.

Há uma grande diferença entre convencer e requer .

Se você encontrar uma maneira de convencer seus colegas a escrevê-los - grande. No entanto, se você criar algumas regras formalizadas e obrigá-los a testes de unidade de gravação, eles vão encontrar uma maneira de superar isso. Como resultado, você vai ter um monte de testes unitários que não valem nada:. Haverá teste de unidade para cada classe disponível e eles vão testar setters e getters

Pense duas vezes antes de criar e impor regras. Desenvolvedores são bons em superá-los.

Primeiro vez você só precisa ir em frente e escrever-los e mostrar às pessoas que vale a pena. Eu encontrei em três projetos que é a única maneira de convencer as pessoas. Algumas pessoas que não codificam (por exemplo, gerentes de projeto júnior) não será capaz de ver o valor até que ele está olhando-los na cara.

No meu time software, temos a tendência de escrever um caso de pequenas empresas sobre estas questões e apresentá-los à gestão, a fim de ter o tempo disponível para criar e acompanhar os testes. Nós explicamos que o tempo necessário para teste é bem feito para quando chegar o momento fulcral e tudo está na linha. Nós também configurar um servidor de compilação Hudson para centralizar o acompanhamento dos testes de unidade. Isso torna muito mais fácil para os desenvolvedores a manter o controle de testes falhando e descobrir problemas recorrentes.

Lembre sua equipe ou os outros desenvolvedores que eles são profissionais, não amadores. Trabalhou para mim!

Além disso, é um padrão da indústria nos dias de hoje. Sem unidade testando experiência, eles são menos desejáveis ??e menos valioso como funcionários a potenciais futuros empregadores.

Como um líder da equipe, que é minha responsabilidade para garantir que meus programadores estão fazendo testes de unidade em todos os módulos em que trabalham. Suponho que, neste ponto, não é mesmo uma questão de como convencê-los, é exigido. Não por vezes, não em projectos bastante largo, o tempo todo. O teste de unidade é a primeira linha de defesa contra colocar algo na produção que você terá de manter. Se algo é colocado em produção que não tenha sido completamente unidade e sistema testado, em seguida, ele vai voltar para mordê-lo. Eu acho que uma das políticas que temos aqui para apoiar este é que, se ele sopra na produção, ou causa problemas, então o programador responsável pela codificação e teste desse módulo vai ser o único que tem que cuidar dos problemas, fazer a limpeza , etc. Isso por si só é um bom motivador.
A outra é que trata-se de orgulho. Eu trabalho em uma loja de cerca de 75 programadores, apesar de que é grande por alguns padrões, é realmente pequeno o suficiente para todos nós conhecer um ao outro. Seu também pequena o suficiente para que nós sabemos o que o outro está trabalhando, e quando ele se move para a produção, estamos cientes de quaisquer Abends, falhas, etc. Se você é cuidadoso, faça o teste de unidade e sistema, as chances de se mover algo a produção significativamente, sem causar falhas aumenta. Pode demorar uma ou duas vezes de mudar algo para produção e não para realizá-lo, mas há grandes recompensas envolvidas em não estragar. É realmente bom ouvir parabéns no corredor quando você mover um projeto e não estragar.

Escrever um monte deles e demonstrar que o teste de unidade melhorou a sua produtividade e da qualidade do seu código. Sem algum tipo de prova, às vezes as pessoas não vão acreditar que vale a pena.

Você poderia tomar alguma inspiração de uma iniciativa a Google. Sua equipe de teste começou a colocar-se exemplos, dicas e benefícios no interior dos cubículos para elevar o perfil dos méritos de automação de teste.

https://testing.googleblog.com/2007 /01/introducing-testing-on-toilet.html

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

Não afiliado a StackOverflow