Você usa testes de unidade no trabalho? Que benefícios você obtém deles? [fechadas]

Eu tinha planejado estudar e aplicar testes de unidade ao meu código, mas depois de conversar com meus colegas, alguns deles me sugeriram que não é necessário e que possui um benefício muito pequeno. Eles também afirmam que apenas algumas empresas realmente fazem testes de unidade com software de produção.

Estou curioso para saber como as pessoas aplicaram o teste de unidade no trabalho e quais os benefícios que obtêm ao usá-los, por exemplo, melhor qualidade do código, menor tempo de desenvolvimento a longo prazo, etc.

alguns deles me sugerem que não é necessário

Bem, no sentido estrito, eles estão certos: testes, revisões de código, controle de origem etc. também não são estritamente necessários . Apenas muito poucos desenvolvedores sensíveis trabalham sem eles a longo prazo. Muitos de nós aprendemos (geralmente da maneira mais difícil, com nossos próprios erros) por que essas são as melhores práticas.

e tem um benefício muito pequeno.

Isso não é verdade na maioria dos casos. Ou seja, se estamos falando de software de produção que deveria estar em uso - portanto em manutenção - nos próximos anos.

Eles também afirmam que apenas poucas empresas fazem testes de unidade com software de produção.

Isso pode ser verdade (embora na minha experiência cada vez menos), mas não há nada a dizer sobre o valor do teste de unidade. Em contraste, a velha piada "Merda é boa - 50 bilhões de moscas não podem estar erradas!" ;-)

você aplicou o teste de unidade em seu trabalho e o que você obtém dele? (por exemplo, melhor qualidade do código, reduzir o tempo a longo prazo etc.)

Venho aplicando testes de unidade em meu trabalho, sempre que possível, há mais de 10 anos. Esse sentimento de confiança no meu código, sabendo que ele funciona - e eu posso provar a qualquer momento, em qualquer lugar, em alguns segundos, repetidas vezes, em vez de apenas acreditar nele - não tem preço. Isso me dá a coragem de refatorar meu código, melhorar seu design ou corrigir bugs, sem o medo de quebrar a funcionalidade existente. Eu nunca voltaria aos velhos tempos de "codifique e ore".

Eu faço unittests, mas não (ou poucos) no trabalho

Os principais benefícios dos testes obtidos são que a refatoração é muito mais fácil e a regressão (ou seja, reintrodução de erros já corrigidos) é notada.

Testar vidas com 'a compilação': você faz o check-out do software com testes em execução e não faz check-in até que todos os testes estejam em execução com sua modificação.

Então, na minha experiência, escrever testes é quase inútil quando feito de um lobo solitário. Quando você sempre precisa corrigir seus testes para acomodar as alterações feitas pelos outros, quando os testes podem ser excluídos por seus colegas de trabalho (ocorreram em meus trabalhos anteriores) porque 'eles não me deixam implantar', etc., eles são apenas um trabalho extra com os benefícios queimados instantaneamente pelo resto da equipe.

Quando toda a equipe concorda (e, em uma equipe de 1 que é fácil), na minha experiência, os testes são um grande benefício para a qualidade, estilo e robustez do projeto.

Mas em uma equipe que acredita honestamente que "apenas algumas empresas testam seu código automaticamente" e estão convencidas de que são uma perda de tempo de qualquer maneira, parece haver pouca esperança de obter os benefícios, mas há uma grande possibilidade de você conseguir responsável pela 'perda de tempo' ao apontar erros.

A melhor chance de introduzir testes seria um pequeno projeto sob sua exclusiva responsabilidade. Lá você teria a oportunidade de brilhar e demonstrar o valor dos testes.

Costumo ficar do lado de seus colegas, mas até certo ponto.

O problema dos testes de unidade é que eles são escritos com frequência e sem pensar em casos triviais, nos quais a investigação superficial do código revela que ele funcionará, não importa o quê. Por exemplo:

def add(x, y)
  x + y
end

Juntamente com uma dúzia de testes para garantir que a adição funcione de fato para casos de uso escolhidos arbitrariamente. Duh ...

A premissa geral por trás do teste de unidade é: se o seu código não contém bugs, é porque você não testou o suficiente. Agora, quando escrever testes de unidade adequados. Respostas:

1. Quando você está testando
2. Quando você está depurando
3. Como você está desenvolvendo coisas realmente difíceis

Vamos analisar cada um, supondo que você esteja desenvolvendo algum tipo de aplicativo da web.

Você escreve algum código para a nova funcionalidade, e deve funcionar razoavelmente bem até agora. Você acessa seu navegador e verifica se ele funciona testando com mais intensidade, certo? Bzzzt! ... Resposta errada. Você escreve um teste de unidade. Se você não fizer isso agora, provavelmente nunca o fará. E este é um dos lugares onde os testes de unidade funcionam muito bem: para testar funcionalidades de alto nível.

Você descobre um bug (quem nunca perde nenhum?). Isso nos leva ao ponto dois. Você volta ao código e começa a seguir as etapas. Enquanto isso, escreva os testes de unidade nos principais pontos de interrupção, onde é essencial ter dados consistentes e corretos.

O último ponto é o contrário. Você está projetando algumas funcionalidades peludas que envolvem muita meta-programação. Ele gera rapidamente uma árvore de decisão com milhares de cenários em potencial, e você precisa garantir que cada um deles funcione. Ao escrever essas coisas, uma simples mudança de aparência aqui ou ali pode ter consequências inimagináveis ​​na cadeia alimentar. Digamos que você esteja projetando uma implementação MPTT usando gatilhos SQL - para que ele possa trabalhar com instruções de várias linhas.

Nesse tipo de ambiente espinhoso, normalmente você deseja automatizar altamente seus testes. Então, você escreve scripts para automatizar a geração de dados de teste e executa uma carga de testes de unidade nesses dados de teste. Uma coisa crucial a não perder de vista ao fazer isso é que você também precisa escrever testes de unidade para o seu gerador de testes de unidade.

Conclusão: testes de unidade, definitivamente sim. Mas poupe-se das funcionalidades básicas - até que você realmente precise delas para depuração ou para garantir que alguma funcionalidade peluda funcione corretamente (incluindo, neste último caso, os próprios testes).

Todo o código deve ser testado. Não há escolha sobre isso.

O código não testado é inútil: não se pode confiar em nada para fazer nada.

Você pode escrever testes de unidade ou pode esperar escrever testes de integração de nível superior ou testes de aceitação.

Os testes de unidade são mais fáceis de escrever, mais fáceis de depurar e mais fáceis de gerenciar.

Os testes de integração são baseados em suposições de que as unidades realmente funcionam. Sem testes de unidade, como você sabe que as unidades funcionam? Como você pode depurar um teste de integração se não conhece as unidades individuais que estão sendo integradas realmente funcionam?

Testes de aceitação, da mesma forma, dependem de todas as peças e peças funcionando. Como você pode saber que as peças e peças funcionam sem ter um conjunto de testes de unidade?

O teste é obrigatório. Todos os testes de nível superior dependem das unidades realmente funcionando.

Isso faz do teste de unidade uma necessidade lógica. Não há outra escolha.

Uso testes de unidade para tudo o que escrevo e não deixo nenhum código não testado passar na revisão sem um caso de teste. (Mas como eu não tenho uma ferramenta de cobertura, preciso raciocinar sobre a cobertura do teste. Uma coisa de cada vez ...)

É bem simples: se você não consegue demonstrar que seu código funciona (e de que maneira melhor do que uma especificação executável na forma de um teste?), Ele não funciona .

Isso me dá:

• Tranquilidade: meu servidor de CI me diz que toda a minha base de código funciona.
• A capacidade de melhorar meu código: eu posso reestruturar meu código - refatorá-lo - sabendo que após a reestruturação eu não quebrei nada.

O teste de unidade é uma disciplina. Como não é necessário que o código funcione, ele geralmente é descartado.

É, no entanto, um método comprovado que leva a um código robusto e com menos erros. Acho que não preciso explicar os benefícios para você, como você já mencionou. Se você observar alguns dos principais projetos de código aberto, sejam bibliotecas javascript, estruturas de pilha completa ou aplicativos de uso único, todos eles usam testes de unidade.

Eu suspeito que seus colegas que recomendam não usá-lo não são programadores. Se forem, digamos que não há muitas pessoas que eu valorizo ​​mais do que pessoas como Martin Fowler ou Kent Beck ;).

Como a maioria das melhores práticas, os benefícios são de longo prazo, você precisa investir algum tempo nisso. Você pode escrever um longo script de código processual, mas todos sabemos que você deseja que o tenha escrito em estilo orientado a objetos quando precisar refatorá-lo após 2 anos.

O mesmo vale para o teste de unidade. Se você escrever testes de unidade para peças críticas em seu aplicativo, poderá garantir que ele funcione conforme o esperado, o tempo todo, mesmo após a refatoração do código. Talvez você codifique tão bem que nunca tenha um erro de regressão. Mas se você não o fizer, ou se um novo programador se juntar à sua equipe, você deseja garantir que os erros do passado não aconteçam novamente. Eu acho que seu chefe também ficaria feliz com isso, em vez de ter que registrar um relatório de bug que ele pensava ter sido resolvido meio ano atrás.

Os testes de unidade requerem linguagem amigável para teste de unidade, design amigável para teste de unidade e problema amigável para teste de unidade.

C ++, design multithread e GUI serão um pesadelo, e a cobertura do problema será assustadora.

.NET, assembly dll single-threaded reutilizável, pura lógica computacional será uma brisa.

Vale a pena, eu realmente não posso dizer.

Você refatorou muito? Você vê "bugs estúpidos" como "off one" no seu código?

O que quer que você faça, não seja aquele cara que critica os outros por "você não tem testes de unidade; portanto, você é péssimo". Se os testes o ajudarem, tente, se não, não é como se fossem uma bala de prata.

Eu quero , mas tive o infortúnio de trabalhar quase inteiramente em empresas que simplesmente não se importam com a qualidade e estão mais concentradas em jogar lixo juntos que meio que talvez funcione. Eu mencionei testes de unidade e recebo um "Hein?" tipo de aparência (a mesma aparência quando menciono os princípios SOLID , ou ORMs, ou padrões de design além de "classe com todos os métodos estáticos" ou seguindo as convenções de nomenclatura do .NET). Eu só estive em uma empresa que entendeu essas coisas e, infelizmente, era um contrato de curto prazo e o departamento foi cortado para cortar custos, para que não houvesse tempo suficiente para realmente aprender.

Eu me envolvi em testes de unidade em projetos fictícios descartáveis, mas não entendi muito bem o TDD / BDD completo, e não ter um mentor que possa ajudá-lo torna muito mais difícil fazer isso corretamente.

Nos os utilizamos. Um grande benefício que obtemos é que nossa estrutura de teste de unidade verifica se há vazamentos de memória e falhas de alocação . Às vezes, o problema está no próprio código de teste da unidade, mas geralmente no código de produção.

É uma ótima maneira de encontrar as coisas que são perdidas em uma revisão de código.

Os testes de unidade (devem) também são executados muito rapidamente e podem ser executados como parte do seu integração contínua após cada confirmação, e também pelos desenvolvedores antes da confirmação. Temos mais de 1.000 que levam menos de 20 segundos para serem executados.

Compare com mais de 40 minutos para testes de automação no nível do sistema e horas / dias para testes manuais. Obviamente, os testes de unidade não são os únicos testes que você deve fazer, mas em um nível de código refinado, eles podem ajudar a encontrar bugs e testar os casos extremos que os testes de sistema / integração não podem tocar. Nosso código deve ser testado com mais de 75% de cobertura de decisão e 100% de cobertura de funções, o que seria muito difícil de obter sem testes de unidade.

Eu diria que os testes de unidade agregam valor, mas não sou um grande discípulo de TDD. Eu encontro o maior benefício com os testes de unidade quando faço o cálculo de motores, ou qualquer tipo de mecanismo realmente e depois as classes de utilidade; os testes de unidade são muito úteis.

Eu prefiro testes de integração automatizados para os blocos mais dependentes de dados, mas tudo depende, eu estou no negócio de dados, então muitos erros são mais dados relacionados em nosso ambiente do que qualquer outra coisa, e para isso os testes de integração automatizados funcionam bem. Verificando os dados antes e depois e gerando relatórios de exceção a partir desses testes.

Portanto, os testes de unidade realmente agregam valor, especialmente se a unidade que você está testando puder ser fornecida com todas as entradas necessárias e funcionar sozinha com a entrada fornecida. Novamente, no meu caso, os mecanismos de cálculo e as classes de utilidade são exemplos perfeitos.

Custos: código mais lento, curva de aprendizado, inércia do desenvolvedor

Benefícios: Geralmente, eu me pude escrever um código melhor quando testei pela primeira vez - em relação ao SOLID ...

Mas o IMHO, o maior benefício que penso, é a confiabilidade em sistemas maiores que mudam com frequência. Um bom teste de unidade salvará o seu alvo (o meu) quando você libera várias versões e pode eliminar uma grande parte dos custos associados aos processos manuais de controle de qualidade. É claro que não garante código livre de bugs, mas pega alguns códigos difíceis de prever. Em grandes sistemas complexos, isso pode ser um benefício muito grande.

Faço alguns testes de unidade no trabalho quando tenho a chance e tento convencer meus colegas a fazer o mesmo.

Eu não sou religioso sobre isso, mas a experiência mostra que os métodos de utilidade e de negócios que foram testados em unidade são muito robustos e tendem a ter poucos ou nenhum erro aparecendo durante a fase de teste, o que no final reduz os custos no projeto.

Onde vi a vantagem real de codificar testes de unidade e tornar a execução de testes de unidade parte do processo diário de criação foi em um projeto com mais de 30 desenvolvedores trabalhando em 3 continentes diferentes. Onde os testes de unidade realmente brilhavam era quando alguém mudava sutilmente uma classe que mantinham sem entender como as pessoas estavam usando essa classe. Em vez de esperar o código chegar ao grupo de testes, houve um feedback imediato quando os testes de unidade de outras pessoas começaram a falhar como resultado da alteração. [É por isso que todos os testes de unidade precisam ser executados rotineiramente, não apenas os que você escreveu para o seu código.]

Minhas diretrizes para testes de unidade são:

1. Teste todas as condições possíveis para o seu código, incluindo entradas, limites incorretos etc.
2. Todos os testes de unidade para todos os módulos devem ser executados regularmente (ou seja, como parte das construções noturnas)
3. Verifique os resultados do teste de unidade!
4. Se alguém encontrar um erro no seu código que passou nos testes, escreva um novo teste para ele!

Eu aprendi recentemente TDD e acho que é muito útil. Dá maior confiança de que meu código esteja se comportando como eu esperava. Além de facilitar qualquer re-fatoração que eu gostaria de fazer. Sempre que um bug é encontrado, você pode garantir que, através do teste, ele não apareça novamente.

A parte mais difícil é escrever bons testes de unidade.

É uma boa referência para o seu código.