O código processual do teste de unidade é eficaz?

Em um projeto atual, os poderes que desejam ter o teste de unidade incorporado em nosso ciclo de desenvolvimento para evitar a quantidade constante de bugs que parecem infiltrar-se em nosso código. O problema é que o código do espaguete é 95% por cento processual, com o qual eu nunca fiz testes de unidade (toda a minha experiência com testes de unidade foi com código OOP)

Portanto, minha pergunta, em poucas palavras, seria sensato prosseguir com o teste de unidade com nossa base de código atual ou sugerir que fosse adiada até que o aplicativo fosse migrado para uma estrutura OOP adequada?

PS: Embora tenha tentado estilizar esta pergunta como independente de idioma, acho que declarar que o aplicativo em questão usa PHP e javascript ajudará a fornecer respostas mais específicas que poderiam responder a essa pergunta, pois, por experiência, essa ocorrência ocorre mais com esses aplicativos.

O teste de unidade funciona bem com objetos, especialmente porque fornece muitos recursos sofisticados, como objetos simulados, o que ajuda a criar testes melhores com mais rapidez.

Dito isto, nada proíbe o teste de unidade em uma base de código processual . No POO, a maioria dos testes de unidade está testando métodos passando alguns parâmetros para eles e esperando um resultado ou uma exceção de um tipo específico. Isso também pode ser feito com o código processual; apenas que, em vez de testar métodos, você testará funções .

Observe que você precisará:

• Isole as funções que você precisa testar e as que não precisa. No POO, isso é fácil: métodos privados não precisam ser testados porque os chamadores nunca poderão acessá-los diretamente. Provavelmente, no seu código processual, algumas funções são assim e não precisam de testes.

• Pense no escopo global . O problema também existe no OOP, mas se você diz que precisa testar o código espaguete, é provável que as pessoas que escreveram esse código tenham maus hábitos, como usar muito o escopo global e fazer algumas coisas malucas, como alterar $_GETou $_POSTmatrizes internas funções.

• Lide com o código fora das funções. Este é um caso mais complicado, mas ainda possível. Você é require_onceuma página para ver o que acontece e captura a saída através de ob_start/ob_get_clean ou faz uma solicitação HTTP do conjunto de testes e analisa a resposta analisando o HTML. Este não é realmente um teste de interface do usuário: aqui, você não se importa se um botão em uma página aparece à esquerda ou à direita ou se um link está em grandes letras maiúsculas em vermelho ou em pequenas letras azuis. O que importa é encontrar alguns elementos HTML por meio do DOM e comparar seu conteúdo com o esperado.

• Teste os códigos de resposta . require_oncecom buffer de saída é bom, mas você também precisa testar como o aplicativo da Web lida com erros. Por exemplo, se o resultado esperado de um teste for 404 Não Encontrado, você deve fazer uma solicitação HTTP para saber qual é a resposta.

sugerimos que seja adiado até que o aplicativo seja migrado para uma estrutura OOP adequada

Faça alguns testes automáticos antes de migrar para outra plataforma, não depois. Adicione mais testes ao fazer a migração, não depois. Se esses testes são "testes de integração" ou testes de unidade, você precisa decidir por si próprio, mas geralmente pode usar sua estrutura de teste xUnit favorita para ambos os tipos.

A maneira mais eficaz de iniciar o teste de unidade é identificar a classe de erros que ocorrem com mais frequência ou o custo mais alto. Em seguida, crie testes que visem esses erros.

Como esses testes são implementados diferirá entre paradigmas e linguagens. As maiores coisas que afetarão sua capacidade de realizar testes de unidade são a qualidade do código; menos que o paradigma usado. Lembre-se de que o teste de unidade consiste em testar uma "unidade" de código isoladamente. Qualquer coisa que afete sua capacidade de isolar "unidades" de código tornará mais difícil o teste.

• uso de globais
• efeitos colaterais
• código fortemente acoplado
• código mal acoplado
• um grande número de condicionais
• "unidades" mal projetadas

Tudo isso terá um impacto maior na dificuldade de testar do que no paradigma da linguagem.

Sempre que houver uma situação em que você possa testar partes do seu código automaticamente, o teste de unidade poderá ser eficaz. Portanto, a questão não é: o código processual pode ser efetivamente testado em unidade, a questão é: ESTE código pode ser testado em unidade. Isso dependerá de quanto estado ele lê e de quanto estado define. Idealmente, a resposta para ambos é zero, mas se não for, você ainda pode testá-lo.

Como sempre, você precisa avaliar a confiança de que o código está correto em relação ao custo de obter essa confiança. Lembre-se de que parte do ganho do teste de unidade está identificando explicitamente as dependências e, nesse sentido, é ainda mais eficaz o código de procedimento do teste de unidade em comparação ao código OOP.

Eu não acho que é possível fazer testes de unidade verdadeiros contra código processual. O principal problema é que cada procedimento provavelmente terá muitas dependências que não podem ser apagadas. Na melhor das hipóteses, os testes serão de integração. Eu fiz uma coisa semelhante há muitas luas atrás com módulos VB6 e módulos VBA no MS Access.

Dito isto, se você pode colocar os andaimes de teste em torno dos métodos que causam mais dor, isso deve ser de valor, certo?