Hablando en términos cotidianos y prácticos, creo que depende totalmente del contexto .
En un equipo med-grande, que trabaja con estándares altos / muy altos (piense en sistemas bancarios, militares, a gran escala, de alto presupuesto o críticos para el negocio), entonces creo claramente que la "depuración" debería ser "el resultado de una prueba" , y claramente Cosas muy diferentes . Idealmente, las pruebas conducen a la depuración (en un entorno de preparación) y en la producción necesitamos cerca de cero.
Las pruebas son amplias, regulares y muy formalizadas, mientras que la depuración es un proceso particular que ocurre ocasionalmente cuando existe la necesidad de corregir una falla particular, lo cual no es obvio y requiere una investigación más profunda del funcionamiento del sistema y los resultados resultantes.
Aquí, en mi mente, las pruebas son algo esencial, mientras que la depuración es una herramienta específica necesaria solo cuando la resolución de una falla es opaca.
Entiendo totalmente la utilidad obvia en TDD para grandes equipos y / o sistemas que simplemente no pueden permitirse el lujo de "tener errores". También tiene mucho sentido para sistemas complejos (a menudo "back-end") o si hay una alta proporción de complejidad en el código en comparación con la salida. Entonces, "probar" tiene una posibilidad realista de informar cuándo y por qué ocurren las fallas. Los sistemas que realizan mucho trabajo complejo y que producen resultados claramente medibles son generalmente fácilmente comprobables, por lo que las pruebas son distintas de la depuración. En estos casos, las pruebas implican un método formalizado basado en procedimientos para confirmar o des-confirmar la coincidencia de expectativas y resultados reales. Las pruebas se realizan todo el tiempo y ocasionalmente nos informan sobre la necesidad de depurar.
Sería encantador si esta fuera una verdad omnipresente, me encantaría si mis ciclos de desarrollo estuvieran delimitados por una salida binaria claramente definida (rojo, verde) pero ...
En mi caso (lo cual es ciertamente particular: trabajar 98% solo en sistemas de administración corporativos centrados en datos y basados en web pequeños, medianos y poco financiados) Realmente no puedo ver cómo TDD podría ayudarme. O mejor dicho, "depuración" y "prueba" son prácticamente lo mismo.
Principalmente, aunque el uso del término "prueba" implica / se relaciona estrechamente con la metodología de TDD.
Sé que esto es totalmente, totalmente no Zeitgeist "rehúye al no creyente, rehúye, rehúye", algo despreciablemente desagradable que decir. Pero pensando en mi contexto, con un sombrero práctico puesto, ni siquiera vagamente, en mi imaginación más salvaje, veo cómo TDD podría ayudarme a entregar más valor por dinero a mis clientes.
O más bien, estoy totalmente en desacuerdo con la suposición común de que "probar" es un proceso formal basado en código.
Mi objeción básica (aplicable en mi * contexto * particular ) es que ...
Si no puedo escribir código que funcione de manera confiable, entonces, ¿cómo diablos se supone que debo escribir código que funcione de manera confiable para probar dicho código presumiblemente por debajo del estándar?
Para mí, nunca he visto ningún ejemplo ni argumento que (en mi contexto particular) me haya entusiasmado lo suficiente como para molestarme en pensar en escribir una sola prueba , podría estar escribiendo un código de prueba ridículamente insustancial en este momento, tal vez "¿mi repositorio devuelve un Usuario? entidad con Nombre == X, cuando lo pido exactamente, ¿y solo eso? ", pero probablemente haya más utilidad en mí al escribir esta transmisión, tal vez-el-internet-realmente-es-solo-puro-tonto-escupir- basura auto-gratificante-salvajemente-bajo-informada-sangrienta-hirviente-derrochadora-tonta, pero solo siento la necesidad de jugar al abogado del diablo aquí. (Espero que alguien me muestre la luz y me convierta, ¿tal vez esto termine dando a mis clientes una mejor relación calidad-precio?).
Podría decirse que "depurar" a veces es lo mismo que "probar". Con esto realmente quiero decir que en mi vida laboral diaria paso al menos un tercio de mi tiempo jugando con la versión local de mi sistema en diferentes navegadores, probando desesperadamente diferentes cosas extrañas en un intento de romper mi trabajo y luego investigando las razones por las cuales falló y corregirlos.
Estoy 100% de acuerdo con la utilidad obvia en el mantra TDD "rojo / verde / refactor", pero para mí (trabajando en un presupuesto bajo, tierra de desarrollo individual de RIA) realmente me encantaría que alguien me muestre cómo podría posiblemente , de manera lógica y vitalmente realista, obtengo cualquier valor adicional al escribir más ( al igual que un código de prueba potencialmente defectuoso ) que al interactuar realmente con el resultado completo (y esencialmente único) de mis esfuerzos que están esencialmente vinculados a la interacción humana real.
Para mí, cuando los desarrolladores hablan de "pruebas", generalmente implica TDD.
Intento codificar como si hubiera pruebas, creo que todos los patrones / prácticas y tendencias que todo este desarrollo centrado en las pruebas ha fomentado son fantásticos y hermosos, pero para mí en mi pequeño mundo "probar" no es escribir más código, en realidad es probarlo en el mundo real lo genera de una manera realista y aproximada, y eso es prácticamente lo mismo que la depuración, o más bien el cambio activo aquí es la "depuración" que es un resultado directo de la "prueba" no automatizada centrada en la producción humana. Esto contrasta con la visión generalmente aceptada de "probar" como algo automatizado y formal, y "depurar" como algo humano y ad-hoc o no estructurado.
Si el objetivo es realmente el valor por el dinero / esfuerzo, y está haciendo aplicaciones interactivas basadas en la web, entonces el resultado del esfuerzo son las páginas web y, esencialmente, cómo reaccionan a la aportación humana , por lo que la mejor manera de "probar" es probar esas páginas web, a través de la interacción humana real. Cuando esta interacción conduce a resultados inesperados o indeseables, se produce la "depuración". La depuración también está estrechamente relacionada con la idea de la inspección en tiempo real del estado del programa. Las pruebas generalmente se asocian con la automatización, que creo que a menudo es una asociación desafortunada.
Si el objetivo es realmente valioso para el esfuerzo, y las pruebas automatizadas son eficientes y altamente beneficiosas, mientras que la depuración es solo una salida de esas pruebas o un mal sustituto de las pruebas automáticas, entonces ¿por qué es el segundo sitio web más visitado del mundo (Facebook ) tan a menudo plagado de errores cegadoramente obvios (para los usuarios, pero claramente no para el equipo de prueba y el código de prueba)?
¿Tal vez es porque se están concentrando en las tranquilizadoras luces verdes y olvidando usar realmente los resultados de su trabajo?
¿Demasiados desarrolladores piensan que las pruebas son algo que haces con el código, y la depuración es algo que haces ocasionalmente con el IDE porque un icono se vuelve rojo y no puedes entender por qué? Creo que estas palabras tienen juicios de valor desafortunados asociados con ellas, que generalmente oscurecen la realidad práctica de lo que debemos enfocar para cerrar las brechas entre las expectativas y los productos.