Falando em termos práticos todos os dias, acho que depende totalmente do contexto .
Em uma equipe de médio porte, trabalhando com padrões altos / muito altos (pense em sistemas bancários, militares, de grande escala, de alto orçamento ou críticos para negócios), acho que claramente "depuração" deve ser "resultado de teste" , e eles são claramente coisas muito diferentes . O teste ideal leva à depuração (em um ambiente de preparação) e na produção precisamos de quase zero de qualquer um.
O teste é amplo, regular e muito formalizado - enquanto a depuração é um processo específico que ocorre ocasionalmente quando há necessidade de corrigir uma falha específica - o que não é óbvio e requer uma investigação mais profunda do funcionamento de um sistema e dos resultados resultantes.
Aqui, na minha mente, testar é algo essencial, enquanto a depuração é uma ferramenta específica necessária apenas quando a resolução de uma falha é opaca.
Entendo perfeitamente a utilidade óbvia no TDD para grandes equipes e / ou sistemas que simplesmente não podem se dar ao luxo de ser "buggy". Também claramente faz muito sentido para sistemas complexos (geralmente "back-end") ou se existe uma alta proporção de complexidade no código em comparação com a saída. Então o "teste" tem uma chance realista de informar quando e por que ocorrem falhas. Os sistemas que executam muito trabalho complexo e ou resultam em saídas claramente mensuráveis geralmente são prontamente testáveis e, portanto, o teste é distinto da depuração. Nesses casos, o teste implica fortemente um método formal e baseado em procedimento para confirmar ou não confirmar a correspondência entre expectativas e resultados reais. Os testes acontecem o tempo todo e ocasionalmente nos informa sobre a necessidade de depuração.
Seria adorável se essa fosse uma verdade onipresente, eu adoraria se meus ciclos de desenvolvimento fossem delimitados por uma saída binária claramente definida (vermelho, verde), mas ...
No meu caso (o que é reconhecidamente particular - trabalhar 98% sozinho em sistemas administrativos corporativos focados em dados, baseados na Web, de pequeno e médio porte, com recursos insuficientes), eu realmente não consigo ver como o TDD poderia me ajudar. Ou melhor, "depuração" e "teste" são praticamente os mesmos.
Principalmente, embora o uso do termo "teste" implique / esteja intimamente relacionado à metodologia do TDD.
Eu sei que isso é uma coisa totalmente, totalmente não-Zeitgeist, "evite os que não acreditam, evite, evite", algo desprezivelmente não-legal de se dizer. Mas, pensando no meu contexto, com um chapéu prático, eu nem sequer vagamente, na minha imaginação mais selvagem, vejo como o TDD poderia me ajudar a oferecer mais valor ao dinheiro para meus clientes.
Ou melhor, discordo totalmente da suposição comum de que "teste" é um processo formal baseado em código.
Minha objeção básica (aplicável no meu * contexto * particular ) é que ...
Se não consigo escrever um código que funcione de maneira confiável - então como diabos devo escrever um código que funcione de maneira confiável para testar o referido código presumivelmente sub-padrão?
Para mim, eu nunca vi nenhum exemplo nem argumento de que (no meu contexto particular) me entusiasmou o suficiente para sequer se preocupar pensando sobre escrever um único teste , eu poderia ser a escrever algum código de teste laughably insubstancial agora, talvez "o meu retorno repositório de um usuário entidade com Nome == X, quando eu solicito exatamente - e apenas - isso? ", mas provavelmente há mais utilidade em escrever esse streaming, talvez a Internet seja realmente apenas pura boba. um lixo auto-gratificante, descontroladamente desinformado, ferozmente imbecil e esbanjador, mas apenas sinto a necessidade de bancar o advogado do diabo aqui. (Esperando que alguém me mostre a luz e me converta, talvez isso acabe dando aos meus clientes uma melhor relação custo-benefício?).
Indiscutivelmente, "depuração" às vezes é o mesmo que "teste". Com isso, quero dizer realmente que, na minha vida profissional diária, passo pelo menos um terço do meu tempo brincando com a versão local do meu sistema em diferentes navegadores, tentando desesperadamente várias coisas malucas na tentativa de interromper meu trabalho e depois investigar as razões pelas quais falhou e corrigi-las.
Eu concordo 100% com a utilidade óbvia no mantra TDD "vermelho / verde / refator", mas para mim (trabalhando com orçamento mediano, solo RIA solo) eu realmente adoraria que alguém me mostrasse como poderia possivelmente , de maneira lógica e vital, obtenha realisticamente qualquer valor adicional ao escrever mais ( apenas como código de teste potencialmente defeituoso ) do que na interação com o resultado total (e essencialmente apenas) de meus esforços, que estão essencialmente vinculados à interação humana real.
Para mim, quando os desenvolvedores falam sobre "teste", geralmente implica TDD.
Eu tento codificar como se houvesse testes, acho que todos os padrões / práticas e tendências que todo esse desenvolvimento focado em testes incentivou são fantásticos e bonitos, mas para mim, no meu pequeno mundo, "testar" não está escrevendo mais código, é realmente testar o mundo real o produz de maneira realista, e isso é praticamente o mesmo que depuração, ou melhor, a mudança ativa aqui é a "depuração", que é um resultado direto do "teste" não automatizado, humano e centrado na produção. Isso contrasta com a visão geralmente aceita de "teste" como algo automatizado e formal e "depuração" como algo humano e ad-hoc ou não-estruturado.
Se o objetivo é realmente valioso em relação ao custo / esforço, e você está criando aplicativos interativos baseados na Web, o resultado do esforço são as páginas da Web e, essencialmente, como elas reagem à contribuição humana - para que "testar" seja melhor alcançado através do teste essas páginas da web, através de interação humana real. Quando essa interação leva a resultados inesperados ou indesejáveis, ocorre a "depuração". A depuração também está intimamente relacionada à idéia de inspeção em tempo real do estado do programa. O teste geralmente está associado à automação, o que eu acho que costuma ser uma associação infeliz.
Se o objetivo é realmente valioso para o esforço, e o teste automatizado é eficiente e altamente benéfico, enquanto a depuração é apenas uma saída desse teste ou um substituto ruim para o teste automatizado, por que o segundo site mais visitado do mundo (Facebook) ) tantas vezes repleta de erros cegamente óbvios (para os usuários, mas claramente não para a equipe e o código de teste)?
Talvez seja porque eles estão se concentrando nas luzes verdes tranquilizadoras e esquecendo de realmente usar os resultados de seu trabalho?
Muitos desenvolvedores acham que o teste é algo que você faz com código e a depuração é algo que você faz ocasionalmente com o IDE porque um ícone fica vermelho e você não sabe por que? Penso que estas palavras têm julgamentos de valor infelizes associados a elas, que geralmente obscurecem a realidade prática em que devemos nos concentrar para fechar as lacunas entre expectativas e resultados.