Estamos a punto de comenzar una nueva parte del proyecto y no parece haber mucho interés en las pruebas unitarias (y no parece que hayan experimentado TDD). Creo que es casi esencial y hace que el mantenimiento sea mucho más fácil. ¿Cuáles son sus puntos de vista?¿Utiliza pruebas unitarias en sus proyectos profesionales?
Gracias
Por cierto: esta es una cuestión independiente del lenguaje, sin embargo, el nuevo proyecto es en Java.
Absolutamente se utilizan pruebas unitarias en nuestros proyectos. Cada clase que no es getters y setters descerebrados es probado por la unidad. Tener pruebas funcionales para tu código te permite refactorizar a tu gusto sin preocuparte de que rompas 50 cosas diferentes a la vez.
Otro aspecto subestimado de las pruebas unitarias es que trae aspectos pasados por alto de un algoritmo a la superficie. Acabo de pasar dos días escribiendo y volviendo a escribir pruebas unitarias usando arreglos ortogonales porque cada vez que se me ocurrió una lista de casos de prueba, descubrí otra dimensión del problema que fue pasada por alto por el líder tecnológico.
Sí. Hemos estado usando TDD por un tiempo ahora. De alguna manera, TDD ha crecido en nosotros y nos gusta este enfoque incremental para lograr una mejor calidad de código. A pesar de la curva de negación inicial en la que crees que ralentizará el desarrollo teniendo pruebas unitarias consistentes y progresivas, al escribir código es esencial en muchos aspectos. Los cambios que rompen la escritura son muy difíciles de realizar debido al marco de pruebas de regresión que se construye de forma incremental. Cuando se hace bien, el código es más robusto y la confianza en el código y en todo el proyecto se ve afectada positivamente.
Escribir pruebas unitarias hoy en día no es una mera élite. Debería ser responsabilidad de cada desarrollador. Cuanto más tarde se encuentre un error en el código, más costará arreglarlo y más difícil será encontrarlo. Esto se convierte fácilmente en una pesadilla de mantenimiento. Tener un fuerte respaldo de pruebas unitarias reduce altamente este riesgo.
Combinando el poder de pruebas de unidad y TDD con un sistema de integración continua así configurado permite la rápida descubrimiento de problemas en las primeras fases del proyecto. Una compilación diaria es imprescindible para evitar problemas futuros y casi seguros.
Me parece que las pruebas unitarias son más que una cosa útil que hacer, también es una responsabilidad del desarrollador. Si libera código que no se ha escrito para pasar un conjunto completo e válido de pruebas unitarias, podría demorar su proyecto o causar problemas en los paquetes, clases, etc. de otra persona.
Además, debe manténgase en contacto directo con su cliente (incluso si es su propia empresa), y trate de alentarlos para que realicen pruebas integrales de aceptación. Es lo mejor para ellos (aunque he descubierto que algunas empresas se resisten a la idea, debido al corto plazo de tiempo requerido para realizar la prueba, a pesar del tiempo que ahorrará si el producto no funciona exactamente que quieren ellos).
Editar
Así que, sí, supongo que el punto que estoy tratando de decir es: sí, lo veo Test Driven Development como el camino a seguir. Otra cosa que no mencioné, por supuesto, es el hecho de que las pruebas ayudan a documentar el código. Sabrá qué se supone que deben hacer los métodos, y se asegurará de que aún lo hagan cuando realice cambios en cualquier etapa posterior.
que he encontrado TDD realmente útil, pero algunos desarrolladores no veo el valor de la misma hasta escribir un código nuevo rompe una prueba más.
estoy interesado en hacerlo, pero no está seguro de cómo empezar a hacerlo con los grandes proyectos que terminan uniéndose en mitad del proceso ... no ha estado involucrado en un verdadero nuevo comienzo de un proyecto dado que en 1996!
Creo que es bastante difícil de probar e introducirlo en proyectos que ya existen. Lo mejor que puede esperar es crear un conjunto de pruebas unitarias a lo largo del tiempo que lo protejan en el futuro, pero es probable que no obtenga la cobertura que el primer diseño le hubiera otorgado. – AshtonKJ
Prueba de la unidad tiene un precio. Primero, debe escribir y validar todo ese código adicional. Y luego puede que tenga que impulsar un costoso cambio de cultura dentro del equipo del proyecto para adoptar las pruebas unitarias.
Este precio bien podría valer la pena pagar para su proyecto específico.La decisión no debe basarse en dogma o anécdota, sino en un análisis cuidadoso de los costos y beneficios.
No estoy de acuerdo con usted porque creo que las pruebas ayudan a reducir los costos a largo plazo porque ayudan a escribir un mejor código. No es un tema dogmático es un problema de calidad – roundcrisis
También sospecho que resultará en costos más bajos, pero eso no significa que no valga la pena analizarlo. –
Existen algunos sistemas en los que la adopción de pruebas unitarias no es apropiada. Por ejemplo, sistemas que no adoptan un enfoque de capas fuertes y dan como resultado la mezcla de lógica de presentación y de negocios. Creo que ya hay una pregunta relacionada con el desbordamiento de pila. –
No TDD estrictamente, pero realizo pruebas unitarias en cada fragmento de código que escribo. Lo pienso de la misma manera que pienso en el control de fuentes y la refactorización; son algo que acaba de hacer do para escribir código de calidad. No pensaría en no en las pruebas de unidad.
Estoy en el mismo campamento. Pruebo unitario (a menudo utilizando los mismos frameworks que los chicos de TDD, mi elección es NUnit), pero no siempre "todo" con todo el mantra de TDD. –
Ojalá pudiera usar la prueba unitaria más en mi proyecto, y me gustaría que mis compañeros de trabajo escribieran al menos algunas pruebas. :)
En mi caso, hay un precio bastante alto para permitir pruebas de unidades y el uso de prácticas de TDD. En su mayoría depende de las herramientas, que son bastante pobres para el marco que estamos utilizando. Si solo las pruebas unitarias podrían haberse realizado con un solo clic para un proyecto completo (o dos clics, en caso de que necesitáramos una prueba específica en este momento), hubiera sido mucho más fácil. Las herramientas que estamos utilizando ahora realmente no rinden frutos: a veces es más fácil detectar un error de forma manual, en lugar de ejecutar la prueba.
Con Java, hay mejores herramientas, ¡así que realmente debería comenzar a escribir pruebas ahora! La depuración es una mierda, prueba las rocas, realmente.
¿Cuál es el marco que estás usando? Sus extraños marcos actuales existentes que no permiten la fácil implementación de pruebas unitarias. – miguelbgouveia
Lamentablemente, no siempre. Nuestros sistemas más críticos para la misión están llenos de pruebas unitarias para garantizar que hagan lo que deben hacer y continúen haciéndolo, independientemente de los desarrolladores. Para otros sistemas, la mayoría de las veces el tiempo de desarrollo es demasiado corto para gastarlo en pruebas de escritura. (sin embargo, al final, el tiempo ganado allí es gastar dos veces en la depuración.)
Sí. Excepto en los casos en que un cliente tiene un arma al lado de mi cabeza para sacar una característica de la puerta al final del día.
Prueba de unidad (estoy pensando JUnit aquí) y TDD son el camino a seguir cuando está comenzando un nuevo proyecto con código nuevo (y necesitará más como CI).
Pero cuando su nuevo proyecto consiste en modificar una antigua base de códigos llena de clases acopladas con 5KLOC en cada una de ellas, la Prueba de unidad es difícil y la mayoría de las veces la línea de tiempo del proyecto no permite una refactorización (o volver a escribir). Si este es el tipo de proyecto que está a punto de comenzar, le recomiendo que lea "Working With Legacy Code" para probar estrategias en el código anterior.
En todos los nuevos desarrollos, ahora hacemos TDD. Para el mantenimiento heredado, creamos pruebas de unidades defectuosas para exponer los defectos informados y crear gradualmente una biblioteca.
Es un choque cultural, pero realmente vale la pena cuando te das cuenta de que estás gastando más tiempo en nuevos desarrollos y menos tiempo para buscar errores.
Realizamos pruebas unitarias después de que una sección de código funcione como realmente desea el cliente. Al principio estábamos haciendo pruebas unitarias demasiado rápido y cuando el cliente cambia de opinión (y ocurre, confía en mí) a menudo tienes que eliminar el código así como la prueba unitaria. Fue demasiado lento y costoso.Estoy para Unit Testing, pero TDD no fue algo económico para nosotros.
Cuando hace la pregunta en un foro de discusión, mucha gente dirá que las pruebas unitarias son "obligatorias", pero en realidad la prueba de la unidad se considerará según los resultados de la encuesta. Ver http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2 para más referencias/material.
No me puedo imaginar trabajando en un proyecto sin pruebas automatizadas ahora (Unidad/Integración etc ...)
De hecho, a menudo dicen
"Si esto se rompe, no es mi culpa"
cuando trabaje en el código del pueblo que no tiene pruebas.
Sí, siempre que puedo. Tengo que apoyar el código que escribo, y sé que una cantidad modesta de tiempo extra dedicado durante el desarrollo me ahorra una cantidad inmodesta de tiempo extra pasado después del lanzamiento.
Si valió la pena escribir, vale la pena probarlo.
TDD es la única forma de volar, me refiero a código. He estado haciendo TDD durante los últimos seis meses en desarrollo profesional. Antes de eso solo era una prueba unitaria. Se necesita tiempo para aprender, pero nunca me iría sin él ahora. –
Estoy totalmente de acuerdo. Empecé como un desarrollador tradicional de estilo cascada, pero sin pruebas unitarias. Ahora me estoy moviendo más hacia un desarrollo ágil y basado en pruebas. Que diferencia hace. Cada prueba hace que te sientas mucho más cerca de la finalización: D – AshtonKJ