Devo exigir testes de unidade dos programadores? [fechadas]

Eu trabalho em um local onde compramos muitos projetos de TI. Atualmente, estamos produzindo um padrão para requisitos de sistemas para a requisição de projetos futuros. Nesse processo, estamos discutindo se podemos ou não exigir testes de unidade automatizados de nossos fornecedores.

Acredito firmemente que o teste de unidade automatizado adequado é a única maneira de documentar a qualidade e a estabilidade do código. Todo mundo parece pensar que o teste de unidade é um método opcional que diz respeito apenas ao fornecedor. Portanto, não faremos nenhuma exigência de testes de unidade automatizados, testes contínuos, relatórios de cobertura, inspeções de testes de unidade ou qualquer outro tipo. Acho essa política extremamente frustrante.

Estou totalmente fora de linha aqui?

Forneça-me argumentos para qualquer uma das opiniões.

Acredito firmemente que testes de unidade automatizados adequados são a única maneira de documentar a qualidade e a estabilidade do código.

O problema é que você não (ou muito raramente, pelo menos) obterá o teste de unidade automatizado adequado , forçando-o às pessoas. Essa é uma boa maneira de fazer testes de merda e aumentar o custo dos projetos.

Pessoalmente, eu procuraria alguma demanda ou SLA que envolva qualidade; independentemente de como isso é realizado. Há 10 anos, os testes de unidade eram pouco frequentes. Você não deseja algemar seus fornecedores em 10 anos quando tivermos melhores métodos para garantir a qualidade, mas sua política desatualizada exige que eles usem da maneira antiga.

Pessoalmente, acho que, no seu caso, você deveria pensar em termos de testes de aceitação:

• Você tem uma caixa preta e espera que se comporte de uma certa maneira.
• Você não pagará até que pague.
• Escreva testes de unidade exercitando o comportamento que você precisa ver e, se eles falharem, precisam corrigi-lo.

Observe também que isso é uma questão de confiança. Se você não confia no seu fornecedor, precisa obter o código-fonte, inspecioná-lo e compilá-lo. Qualquer coisa menos do que isso significa que você, pelo menos confiar neles alguma .

Acredito firmemente que testes de unidade automatizados adequados são a única maneira de documentar a qualidade e a estabilidade do código.

Surpreende-me quão comum é esse pensamento. Automatizado, sim. Teste de unidade (sozinho), não. Há muito mais testes automatizados de software do que testes unitários. E quanto à integração, sistema, funcional, controle de qualidade? Por algumas razões, as pessoas tendem a pensar: "Ok, então temos testes unitários adequados. Concluído o teste, chame sexta-feira à noite!" . O teste de unidade é apenas o começo.

De qualquer forma, de volta ao tópico. Concordo com outras pessoas dizendo que forçar qualquer coisa em alguém provavelmente produzirá resultados opostos aos desejados. Você nunca sabe como a equipe funciona, talvez eles tenham um departamento de testes no valor de um milhão de dólares e nunca escrevessem um único teste de unidade.

No meu primeiro emprego, eu costumava trabalhar em um local onde tínhamos 0 testes de unidade (éramos um bando de juniores jogando coisas mais ou menos sérias). Acredite ou não, funcionou. Claro, ninguém ficou sabendo por que esse bug foi corrigido ou o que foi corrigido, mas funcionou. Houve momentos em que algum bug absolutamente aleatório apareceu, mastaco de beisebol e risco de queimar seu apartamentoalgumas horas extras podem fazer maravilhas. Talvez seus fornecedores usem técnicas semelhantes ?

Duvido muito que sua gerência esteja disposta a pagar pelos testes de unidade adequados em um contrato. O teste de unidade adequado custa tanto quanto o código que eles testam, mas oferece pouco valor percebido ao usuário final para que eles não sejam vistos como igualmente valiosos. Nenhuma empresa de desenvolvimento de qualidade estará disposta a gastar o esforço de desenvolvimento em testes de unidade por um custo menor do que em outras partes, porque não está sofrendo com o trabalho, pode conseguir mais 2 contratos que levam o mesmo tempo sem requisitos de teste de unidade.

Testes de unidade exigentes provavelmente aumentarão as cotações recebidas para um nível irracional e provavelmente será a primeira concessão feita a obter um preço mais baixo.

O custo de não ter testes de unidade depende de quanto você estenderá / suportará o código por conta própria. Conseguir inspecionar partes do código para ter uma idéia de qualidade também seria importante.

Se você está apenas comprando os projetos para poder usá-los como uma biblioteca de terceiros e não acredita que irá modificá-los, o risco de código de qualidade inferior é menor, desde que ele realmente funcione.

Essas são, em última análise, decisões de negócios, embora você tenha que garantir que quem está tomando a decisão também esteja ciente da avaliação técnica. Se você precisar explicá-lo à gerência, explique como é comprar um carro usado. Em última análise, cabe ao comprador decidir se vale a pena, mas levá-lo a um mecânico é uma boa idéia para que você saiba que não está recebendo um limão.

Você está pagando, pode exigir o que quiser, incluindo cópias / relatórios de todos os seus testes de unidade.

Você pode até escrever os testes, ou pelo menos as próprias especificações.

Concordo com a sua opinião de que é uma medida muito boa da qualidade do código. Se um fornecedor recusasse essa demanda, tocaria um alarme, por que eles não o desejariam - eles têm baixos padrões de qualidade e atalhos?

Você está absolutamente certo de que seu projeto precisa de testes de unidade automatizados, testes contínuos, relatórios de cobertura e inspeções de testes de unidade.

No entanto, as coisas exigentes não alcançarão os resultados que você deseja, conforme detalhado por outros.

Seu desafio é explicar e persuadir as pessoas - habilidades muito mais difíceis!

Eu começaria inicialmente com a gerência, explicando os prós e contras dos testes e os benefícios futuros. Tenha cuidado para não comunicar a emoção por trás de afirmações como 'Eu escrevo testes de unidade PROPER' (letras maiúsculas suas). Você não quer 'gritar' as palavras (como implica TODAS AS CAPS), convencer e convencer as pessoas, para que elas mesmas possam escolher a solução certa.

Por fim, se você não pode introduzir essas metodologias e adotá-las onde está, além disso, se você é tão apaixonado por elas quanto declara (o que é bom!), Eu entraria em uma empresa diferente, pois há muitas que valorizam essas coisas e recebê-lo a bordo. Apenas certifique-se de ser franco com eles em entrevistas, para que eles saibam onde estão suas paixões e se você será um bom candidato.

Forçar testes automatizados em alguém não alcançará os resultados que você deseja, como @Joachim Sauer e @Telastyn apontaram em seus comentários. Para muitas pessoas, o teste de unidade automatizado é uma enorme mudança de pensamento. Porque muitas pessoas escrevem código que funciona, mas não é muito testável. Eu poderia escrever uma página da Web do ASP.NET em que toda a lógica, consulta ao banco de dados, regras de negócios, objetos etc. esteja no código por trás. A página funcionará? Sim. É testável usando testes de unidade automatizados? Absolutamente não. Se um fornecedor não tiver testes de unidade automatizados, será necessário um grande esforço para aprender a escrever corretamente os testes de unidade e, como resultado disso, reescreva ou re-fatore seu código para torná-lo mais facilmente testável. Provavelmente, eles vão repassar esse custo para você.

O fato é que o fornecedor está fornecendo um produto, seja um aplicativo .dll ou Windows, e você espera que ele funcione 99% do tempo. Claro que existem erros aqui e ali, mas na maioria das vezes deve funcionar. Essa é uma expectativa razoável, especialmente se o fornecedor quiser reter seus negócios. Se for uma caixa preta, não importa realmente como eles funcionam, eles poderiam usar uma onda humana de testadores ou uma sala cheia de macacos pressionando as teclas aleatoriamente. Enquanto funcionar. Mas eles precisariam fornecer algum tipo de outra documentação sobre como usá-lo.

No entanto, se eles fornecerem o código-fonte para que você possa modificá-lo, esperaria testes de unidade. Eu não trabalharia com uma empresa que não fornece testes de unidade. De que outra forma você saberia que uma modificação que você faz não faz a coisa toda?

O teste de unidade é uma indicação de como esse fornecedor lida com riscos durante o ciclo de desenvolvimento. Aqueles que usam testes de unidade valorizam o risco de redução e a qualidade desses testes é uma indicação de quanto risco foi gerenciado.

Com isso dito, os testes de unidade não definem qual o nível de risco que o projeto está tentando enfrentar. Também não desempenha nenhum papel na redução de risco introduzida por más práticas de programação.

Portanto, você pode ter um fornecedor que possua práticas sólidas de teste, mas continua a escrever código altamente arriscado, enquanto outro fornecedor que faz teste zero, mas escreve código de baixo risco. Se os dois fornecedores oferecerem o mesmo produto, é melhor optar pelo fornecedor de baixo risco.

Isso só pode ser medido através da entrevista, orientação e aprendizado sobre as personalidades e habilidades das pessoas envolvidas com esse fornecedor.

Encontrei este artigo sobre a compra de software personalizado bastante útil: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

A pergunta número um que eles recomendam é se o fornecedor faz testes.

Concordar com outras pessoas que exigem testes unitários levaria a testes para fins de teste; algo que é muito contrário ao que você deseja.

No processo de verificar seus fornecedores; pergunte a eles qual é o processo de desenvolvimento deles , pois o teste é apenas uma parte desse processo.

Eles têm um processo automatizado de criação? Eles seguem algum paradigma de gerenciamento? Eles têm testadores devidamente treinados e uma equipe independente de garantia de qualidade ? E os padrões de documentação?

Isso o ajudará a julgar a qualidade geral do processo e, por sua vez, a qualidade do que eles produzem.

Parece-me que incluir esse requisito traria pouco benefício prático, uma vez que seria impossível fazer cumprir.

Você pode exigir o código para os testes reais ou um relatório de quais testes reais foram executados e aprovados. Se for um projeto proprietário, o fornecedor provavelmente não gostaria de fornecer isso, pois provavelmente seria altamente sugestivo dos detalhes do código e pode se arrepender ao ser feito para fornecer detalhes de implementação de baixo nível e saber como fazer suas empregos. Em algum momento, tem que haver alguma confiança.

Caso contrário, eles também podem te impressionar, mas apenas marque a caixa ao lado de "executa um conjunto de testes de unidade" para cumprir o requisito escrevendo um único teste que passa se o utilitário for compilado e executado ou um método similar. esforço.

Portanto, embora os testes de unidade automatizados sejam uma prática louvável, não acho prático insistir nisso de fornecedores externos.

Como muitas pessoas apontaram, forçar os fornecedores a escrever testes de unidade (ou melhor, uma combinação de testes automatizados de unidade e integração) para cumprir um contrato provavelmente não produzirá resultados de alta qualidade. Por outro lado, concordo que o teste automatizado é de longe o melhor método atualmente em uso para garantir a qualidade do código.

Acho que o código escrito com testes de unidade é muito mais fácil de manter do que o código que foi escrito primeiro e que os testes de unidade foram adicionados posteriormente. Força a modularidade e as dependências mínimas. Os testes de integração também são necessários para verificar a exatidão do código, mas eles não têm o mesmo impacto na qualidade do código que está escrito. Em essência, os testes de integração automatizados podem ser adicionados após o fato, mas os testes de unidade têm mais impacto quando escritos com o código original.

Meu conselho para a sua situação é procurar fornecedores que preferem escrever código com testes de unidade e escolhê-los em vez de fornecedores que tendem a não escrever código com testes unificados. Se a gerência pagar por isso, coloque testes automatizados no contrato, mas SOMENTE SE O FORNECEDOR FOR USADO PARA ESCREVER O CÓDIGO COM OS ENSAIOS DA UNIDADE.

Vamos esclarecer as prioridades primeiro ...

No seu papel de cliente, sua principal preocupação não é o teste de unidade

Se você estiver usando fornecedores que produzem software para você, não deverá se preocupar se eles estão usando uma metodologia ou outra. Sua aposta é adquirir algum tipo de solução que ajude a alcançar seus objetivos. A única coisa com que você deve se preocupar é se essa solução é aceitável ou não. É por isso que temos testes de aceitação , pois é de sua responsabilidade garantir que você obtenha o que deseja. É no momento crucial da aceitação do cliente que o dinheiro será transacionado dos bolsos da sua empresa para o bolso do fornecedor.

Você pode exigir testes de unidade como requisito de entrega, mas há vários problemas herdados com eles, o mais grave é que não há uma maneira segura de determinar previamente as métricas:

• Qual é a quantidade aceitável de testes de unidade?

Deve haver 10 testes? Como cerca de 100 testes? Como cerca de 1000 testes? Na verdade, é bastante difícil determinar no início quantos testes serão necessários. O número real é indeterminável, realmente ... como o problema de parada ... mas não estamos resolvendo esse problema.

Você só quer um software com testes de unidade para poder continuar o desenvolvimento. Os testes de unidade não informam o que você quebrou ainda, mas são incrivelmente adequados para informar quando o código tem um erro de regressão.

• O que é um nível aceitável de cobertura de código?

"100%, é claro!" você pensaria. Infelizmente essa métrica é enganosa; mesmo se você tivesse 100% de cobertura de código, tem certeza de que tudo está funcionando conforme o esperado? É possível ter 100% de cobertura, mas isso não é feito.

O que você realmente precisa fazer é o teste exploratório, ou seja, encontre alguém que seja realmente bom em quebrar coisas e deixe-o fazer o teste. Para encontrar os bugs que nenhum desenvolvedor sequer pensou.

Além disso, às vezes 100% é inatingível com testes de unidade puros, se você tiver alguns hacks de desempenho necessários e usar padrões de design difíceis de testar (pesquise "singleton" e "tdd" em seu mecanismo de pesquisa favorito e você encontrará alguns exemplos).

Você deseja que o software entregue funcione e o documento de especificação é sua única garantia.

Você precisará de um nível mais alto de teste

Seu documento de especificação deve ser verificado de alguma forma. Cada ponto deve ser discutido com seus fornecedores, com metas e critérios de aceitação claros. Uma organização de controle de qualidade que funcione bem (ou um testador impressionante, se você estiver com um orçamento e um escopo limitado) forneceria os casos de teste para verificar esses critérios de aceitação. Você também precisa de alguém para verificar esses critérios de aceitação.

Existem várias maneiras de verificar seus objetivos e, se alguém me disser que você não pode definir metas de qualidade, desempenho e eficiência sãs, acertarei em cheio com livros grandes e pesados ​​sobre testes exploratórios, de desempenho e de usabilidade, respectivamente. Pode ser fácil exagerar nos objetivos, mas o conhecimento e a comunicação o ajudarão a estabelecer objetivos realistas.

Não sou advogado, mas a maioria dos contratos de projeto (que é basicamente a mãe de todas as especificações do projeto) que li geralmente possui um critério de taxa de defeitos que estipula quantos bugs são considerados aceitáveis. Os erros são geralmente determinados por gravidade, os erros de interrupção encontrados pelo controle de qualidade têm uma tolerância baixa, enquanto defeitos menores têm uma tolerância alta. Em projetos reais, é difícil exigir que o software tenha 0 defeitos. Os prazos geralmente acabam com essa prática. É nessas situações que você precisa começar a negociar o escopo.

A maioria dos softwares fornecidos que eu vi geralmente não são entregues com testes de unidade. Você pode argumentar que os fornecedores devem ser profissionais o suficiente para fornecer isso, no entanto, a principal razão pela qual você deseja que os testes de unidade sejam entregues é garantir que você não receba erros de regressão e também habilitar a refatoração. Na vida real, com projetos em prazos apertados, tanto o fornecedor quanto o cliente estarão diminuindo o escopo e os testes de unidade geralmente saem pela janela e são removidos da lista de produtos necessários.

É um pouco triste que o software de código aberto de alto perfil seja fornecido com testes de unidade, mas um desenvolvedor de software profissional não pode, certo?

Então, quando eu, como cliente, me preocupo com o teste de unidade?

Eu diria que a única vez em que você realmente se importaria com o teste de unidade é se o software entregue é um componente auto-suficiente que não é executado como um programa independente, para o qual o teste mais grosseiro que você pode fazer é um teste de unidade . As bibliotecas de classes seriam um tipo de produto que pode ser entregue juntamente com testes de unidade.

Como você sabe que os fornecedores não estão escrevendo testes de unidade.

Talvez a gerência e o fornecedor tenham tido uma reunião e o vendedor tenha dito que o código custa $ X e os testes unitários custam $ Y. A gerência de penny beliscar disse que só queremos o código.

O fornecedor decidiu escrever testes de unidade de qualquer maneira (por causa da qualidade) e simplesmente não compartilhá-los com você (por causa da vantagem competitiva).

Agora você precisa fazer alguns ajustes importantes no software. Como você possui o código, pode fazê-lo sozinho ou contratá-lo de forma competitiva (não necessariamente para o fornecedor original). Porém, como você não comprou os testes de unidade, o fornecedor original poderá executar um trabalho de qualidade comparável a um preço mais barato que qualquer concorrente.

Existem muitos projetos que são muito bem-sucedidos, apesar de não usarem testes de unidade. Basta olhar para o kernel do linux, é um projeto gigantesco com uma complexidade muito além do que você encontraria em qualquer projeto normal, e ainda funciona. Portanto, se o resultado for um bom software, você não deve se importar como eles o alcançaram.

Não, você não precisa necessariamente exigir unidades de teste completas e automatizadas. É mais importante que eles forneçam documentos de estratégia de teste adequados. Estamos indo bem assim.