Recientemente di una charla sobre depuración para la comunidad Java de Londres. Durante la parte de preguntas y respuestas de la charla, alguien me preguntó sobre mi enfoque del desarrollo basado en pruebas. En el pasado, miré esa práctica bajo una luz más positiva. Escribiendo muchas pruebas. ¿Cómo puede ser eso malo?  Pero a medida que pasó el tiempo, lo veo bajo una luz diferente.  Lo veo como una herramienta muy limitada que tiene casos de uso muy específicos. No encaja en el tipo de proyectos que construyo y, a menudo, dificulta los procesos fluidos que se supone que debe promover. Pero retrocedamos por un segundo. Me gustó mucho   que separa los tipos y problemas en TDD. Pero simplifiquemos un poco, aclaremos que todo PR debe tener una buena cobertura. Esto no es TDD. Es solo una buena programación. este post  TDD es más que eso. En él, necesitamos definir las restricciones y luego resolver el problema. ¿Es ese enfoque superior a resolver el problema y luego verificar que las restricciones sean correctas? Esa es la premisa central de TDD frente a solo escribir una buena cobertura de prueba.  El bueno  TDD es un enfoque interesante. Es especialmente útil cuando se trabaja con lenguajes poco escritos. En esas situaciones, TDD es maravilloso, ya que cumple el papel de un compilador y un filtro estrictos.  Hay otros casos en los que tiene sentido. Cuando estamos construyendo un sistema que tiene entradas y salidas muy bien definidas. Me he encontrado con muchos de estos casos al crear cursos y materiales. Cuando se trabaja con datos del mundo real, esto sucede a veces cuando tenemos un middleware que procesa datos y los genera en un formato predefinido.  La idea es construir la ecuación con las variables ocultas en el medio. Entonces la codificación se convierte en llenar la ecuación. Es muy conveniente en casos como ese. Codificar se convierte en llenar los espacios en blanco.  El malo  “El desarrollo basado en pruebas   contabilidad de doble entrada. Misma disciplina. Mismo razonamiento. Mismo resultado.” – tío Bob Martín ES  Yo diría que las pruebas son un poco como la contabilidad de doble entrada. Sí. Deberíamos tener pruebas. La pregunta es ¿debemos construir nuestro código basado en nuestras pruebas o viceversa? Aquí la respuesta no es tan simple.  Si tenemos un sistema preexistente con pruebas, entonces TDD tiene todo el sentido del mundo. Pero probando un sistema que aún no estaba construido. Hay algunos casos en los que tiene sentido, pero no tan a menudo como uno pensaría.  El gran reclamo de TDD es “su diseño”. Las pruebas son efectivamente el diseño del sistema, y luego implementamos ese diseño. El problema con esto es que tampoco podemos depurar un diseño. En el pasado, trabajé en un proyecto para una importante empresa japonesa. Esta empresa tenía uno de los conjuntos de libros de diseño anexos más grandes y detallados. Basándose en estas especificaciones de diseño, la empresa construyó miles de pruebas. Se suponía que íbamos a pasar una gran cantidad de pruebas con nuestro sistema. Tenga en cuenta que la mayoría ni siquiera eran automáticos.  Las pruebas tenían errores. Hubo muchas implementaciones en competencia, pero ninguna de ellas encontró los errores en las pruebas. ¿Por qué? Todos usaron el mismo código fuente de implementación de referencia. Fuimos el primer equipo en omitir eso e implementar una sala limpia. Perpetuó estos errores en el código, algunos de ellos eran errores graves de rendimiento que afectaron a todas las versiones anteriores.  Pero el verdadero problema fue el lento progreso. La empresa no podía avanzar rápidamente. Los defensores de TDD se apresurarán a comentar que un proyecto de TDD es más fácil de refactorizar ya que las pruebas nos dan una garantía de que no tendremos regresiones. Pero esto se aplica a proyectos con pruebas realizadas después del hecho.  Lo peor  TDD se centra en gran medida en las pruebas unitarias rápidas. No es práctico ejecutar pruebas de integración lentas o pruebas de ejecución prolongada que pueden ejecutarse durante la noche en un sistema TDD. ¿Cómo verifica la escala y la integración en un sistema importante?  En un mundo ideal, todo simplemente encajará en su lugar como legos. No vivo en un mundo así, las pruebas de integración fallan gravemente. Estas son las peores fallas con los errores más difíciles de rastrear. Prefiero tener una falla en las pruebas unitarias, por eso las tengo. Son fáciles de arreglar. Pero incluso con una cobertura perfecta, no prueban la interconexión correctamente. Necesitamos pruebas de integración y encuentran los errores más terribles.  Como resultado, TDD enfatiza demasiado las pruebas unitarias "agradables de tener", sobre las pruebas de integración esenciales. Sí, deberías tener ambos. Pero debo tener las pruebas de integración. Esos no encajan tan claramente en el proceso TDD.  Pruebas impulsadas por la derecha  Escribo probando la forma que elijo caso por caso. Si tengo un caso en el que la prueba por adelantado es natural, lo usaré. Pero para la mayoría de los casos, escribir el código primero me parece más natural. Revisar los números de cobertura es muy útil al escribir pruebas y esto es algo que hago después del hecho.  Como mencioné antes, solo compruebo la cobertura para las pruebas de integración. Me gustan las pruebas unitarias y monitorear la cobertura allí, ya que también quiero una buena cobertura allí. Pero para la calidad, solo importan las pruebas de integración. Un PR necesita pruebas unitarias, no me importa si las escribimos antes de la implementación. Deberíamos juzgar los resultados.  Mala automatización  Cuando   estaba construyendo sus fábricas Model 3, entró en un infierno de producción. La fuente de los problemas fue su intento de automatizar todo. El   se aplica perfectamente a la automatización. Algunas cosas son muy resistentes a la automatización y hacen que todo el proceso sea mucho peor. Tesla Principio de Pareto  Un punto en el que esto realmente falla es en las pruebas de interfaz de usuario. Soluciones como Selenium, etc. lograron grandes avances en las pruebas de front-end web. Aún así, la complejidad es tremenda y las pruebas son muy frágiles. Terminamos con pruebas difíciles de mantener. Peor aún, encontramos que la interfaz de usuario es más difícil de refactorizar porque no queremos reescribir las pruebas.  Probablemente podamos cruzar el 80 % de la funcionalidad probada, pero hay un punto de rendimiento decreciente para la automatización. En esos entornos, TDD es problemático. La funcionalidad es fácil pero construir las pruebas se vuelve insostenible.  Finalmente  No estoy en contra de TDD pero no lo recomiendo y efectivamente no lo uso. Cuando tenga sentido comenzar con una prueba, podría hacerlo, pero eso no es realmente TDD. Juzgo el código basado en los resultados. TDD puede proporcionar excelentes resultados, pero a menudo enfatiza demasiado las pruebas unitarias. Las pruebas de integración son más importantes para la calidad a largo plazo.  La automatización es genial. Hasta que se detiene. Hay un punto en el que las pruebas automatizadas tienen poco sentido. Nos ahorraría mucho tiempo y esfuerzo aceptar eso y enfocar nuestros esfuerzos en una dirección productiva.  Esto se debe a mi preferencia como desarrollador de Java al que le gustan los lenguajes estrictos y con seguridad de tipo. Los lenguajes como JavaScript y Python pueden beneficiarse de un mayor volumen de pruebas debido a su flexibilidad. Por lo tanto, TDD tiene más sentido en esos entornos.  En resumen, la prueba es buena. Sin embargo, TDD no hace mejores pruebas. Es un enfoque interesante si te funciona. En algunos casos es enorme. Pero la idea de que TDD es esencial o incluso que mejorará significativamente el código resultante no tiene sentido.  También publicado  aquí.

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Por qué no creo que TDD sea esencial

Por qué no creo que TDD sea esencial

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps