He participado en muchos proyectos, tanto antiguos como nuevos, y una cosa que tienen en común es que casi ninguno de ellos ha estado usando pruebas unitarias. Prefiero usarlo, pero a menudo el cliente no está listo para pagar, y supongo que el código funciona como debería.¿Realmente está usando pruebas unitarias?
Entonces, ¿usa pruebas unitarias en sus proyectos, o confía en sus habilidades de codificación?
El uso de pruebas unitarias es una habilidad de codificación.
Me parece que agrega muy poca sobrecarga al tiempo de codificación. Además de eso, el código producido tiende a ser mucho más fácil de entender y refactorizar, con una reducción incalculable en el tiempo de mantenimiento.
Una discusión completa de los beneficios aquí: Is Unit Testing worth the effort?
The TDD mencionado en la discusión es un punto clave (para mí). No es necesario primero escribir el código y luego las pruebas por separado, sino escribir las pruebas como parte del proceso de desarrollo – Touko
Buen punto. El problema es que cuando trabajo con otras personas, a menudo no tienen idea de qué son las pruebas, simplemente piensan en probar como "abrir el navegador y probar ejecutar la función. ¿Funciona para mí? Genial". Por cierto, StackOverflow no está especialmente probado (ver el video de PDC sobre MVC). ;-) –
Cuando utiliza la base de datos MongoDB en su aplicación, creo que Unit Testing sería incluso más útil, especialmente al probar las operaciones CRUD de sus Entidades, porque MongoDB deja al desarrollador de la aplicación asegurarse de que se mantenga la integridad referencial de clave externa. A diferencia de las bases de datos RDMS, MongoDB y muchas otras bases de datos NoSQL dejan la aplicación de asociaciones de datos válidas para el desarrollador de la aplicación. –
A menudo utilizo pruebas unitarias para algoritmos matemáticos complejos, por ejemplo para funciones como LineIntersectsLine donde puede definir algunos ejemplos importantes para probar. Después de eso, es más fácil controlar esta función. Simplemente puede reescribir/optimizar y probar si todavía funciona, o puede agregar nuevas pruebas si encuentra errores y luego intenta corregirlos.
Después de llegar en un par de proyectos que estaban en producción, pero requieren importantes nuevas funcionalidades, una de mis líneas de fondo como una ventaja técnica puesta en marcha de un proyecto es que la unidad -testes son una necesidad.
Simplemente cuesta demasiado intentar y reescribir el código que se ha escrito sin pruebas unitarias. El código está invariablemente mal estructurado (¿un servicio web de miles de líneas en un solo código detrás de alguien?) Y hacer cambios en él (incluso cuando está bien estructurado) sin introducir errores es un proceso realmente doloroso.
Esto es particularmente cierto cuando un proyecto entra en modo de lucha contra incendios (y no tener pruebas unitarias contribuye a que los proyectos también entren en ese estado) - los clientes se ponen malhumorados, han perdido la fe en el proyecto, pocas cosas peores que siendo el pobre chico tratando de obtener la próxima solución sin introducir una pila completa de errores de regresión, y sin siquiera tener pruebas unitarias.
Esas situaciones pueden evitarse tan fácilmente o al menos mitigarse explicando el valor de las pruebas por adelantado. Por supuesto, hay situaciones en las que las pruebas unitarias no son tan importantes, pero son realmente la excepción.
Así que sí - Insisto en pruebas unitarias y he dedicado mucho tiempo a solucionar los problemas causados por otros desarrolladores que confiaban en sus habilidades de codificación.
Las pruebas unitarias no pueden ser una ocurrencia tardía, es y tiene que ser algo que se relaciona con su diseño. Iría tan lejos como para decir que incluso si nunca escribe o llama a un solo examen de unidad, los beneficios que tiene en el liderazgo de un software impulsado por componentes valen el esfuerzo el 95% del tiempo.
Escribir y ejecutar pruebas unitarias es parte de un proceso de codificación saludable, no es una adición que el cliente debe tener la opción de pagar o no pagar.
estrategia de prueba es un problema de codificación al igual que cualquier otra: ¿qué estructuras de datos a utilizar, las convenciones de denominación de variables, las normas de comentarios, etc.
Su elección de la palabra "saludable" conjuró una imagen de una sala de emergencias: "¿Quiere antiséptico, por una tarifa adicional?" +1 –
Afortunadamente, el entorno de codificación se parece más a la investigación médica y menos a la unidad de trauma. – JeffO
Estoy de acuerdo con Ken que las pruebas de unidad es parte del desarrollo de software.
Acerca de la pregunta del costo, es cierto que escribir el código más la prueba unitaria es más larga que escribir solo el código. Sin embargo, cuando escribe el código junto con sus pruebas, que se llama TDD - Test-Driven Development, finaliza con "clean code that works". Cuando solo escribes el código, entonces tienes que hacerlo funcionar, lo que puede ser largo y doloroso.
Otra ventaja es que usted sabe dónde está, ya que el código que se ha escrito ya ha sido probado por la unidad.
Para responder a su pregunta, sí, estoy usando pruebas unitarias en mis proyectos cuando es posible. Escribo pruebas unitarias para todo el código nuevo y me esfuerzo por obtener el código heredado.
Las pruebas unitarias son una parte esencial del desarrollo, y (lo he encontrado) reducirán el tiempo hasta la finalización de un proyecto al tiempo que mejoran la calidad general, especialmente cuando se realiza en un entorno TDD.
Realizo la prueba de la unidad. Actualmente estoy construyendo un motor de validación de restricciones y mis clientes lo quieren a prueba de balas. Bueno, sin una prueba unitaria, me moriría de estrés ...
Así que sí, ¡lo uso!
La mayoría de las funciones que escribo tienen pruebas. Como muchos han dicho allí, las pruebas unitarias son una parte esencial de la ingeniería de software. Entonces, para responder a su pregunta, sí, REALMENTE escribo y hago pruebas.
Además, con continuous integration, las pruebas de regresión se automatizarán y se informarán constantemente.
Utilizo pruebas unitarias, y tdd, siempre que puedo. Sin embargo, en mi experiencia para cada defensor de prueba de unidad hay tres o más desarrolladores que realmente no creen que escribir pruebas de unidad vale la pena el esfuerzo, y que ralentiza el desarrollo. Sin embargo, estas personas tienden a guardar silencio, por lo que es poco probable que veas muchas aquí.
Soy un gran admirador de las pruebas unitarias, principalmente porque es completamente adictivo: el ciclo "prueba-código-ver horrible bar-fix-test-see lovely green bar" en JUnit pone en peligro las endorfinas.
Me gusta la analogía de Bob Martin: imagine que es un cirujano. ¿Qué le diría a un paciente que quería pagar la cirugía pero le dijo que se saltee la colada antes de tiempo?
Cuando un cliente me contrata para codificar me contratan como profesional, como alguien con las habilidades y la disciplina de un profesional. Mi trabajo es darles "el código simplemente funciona como debería", y Sé la mejor manera de hacerlo es usar TDD.
En cuanto a confiar en mis habilidades de codificación, me parece que mis habilidades de codificación mejoran cuando uso TDD y confío en las pruebas de mi unidad para corregirme cuando rompo una prueba. Aprende a usar muchas funciones del lenguaje porque puede realizar un ajuste para probar una suposición.
Otro recordatorio muy útil de por qué quieres probar la unidad donde sea que acabes de aparecer en esta publicación: Top 12 Reasons to Write Unit Tests Necesito tener ese grabado en mis retinas.
Puedo testificar personalmente sobre el valor de pensar sobre cómo se probará algo desde el principio, con pruebas desarrolladas en cada iteración. Necesito ser más sistemático, yo mismo. Estoy imprimiendo esa lista ahora mismo.
Sus clientes probablemente ahorrarían dinero en general si se llevaran a cabo las pruebas unitarias. Algunos de los errores evitados por las pruebas unitarias son mucho más una responsabilidad si se encuentran más adelante en la etapa de desarrollo que en las pruebas unitarias. Ahorra mucho dolor de cabeza en el futuro, ahora que lo uso, no creo que pueda regresar.
Mi empresa fabrica componentes de sistemas para varias empresas en la industria aeroespacial. La FAA requiere Modified Cobertura/Decisión Condición para el nivel de calidad de software de vuelo Un Críticos de Seguridad (DO-178-B) Así que para la verificación que hacer (de nuevo de la DO-178-B):
Análisis de todo el código y la trazabilidad de las pruebas y los resultados de generalmente se requieren todos los requisitos (dependiendo del nivel de software).
Este proceso normalmente implica también:
Requisitos herramientas de prueba basados
herramientas de análisis de la cobertura de código
Otros nombres para las pruebas realizadas en este proceso pueden ser:
U pruebas de nit
Integración prueba
cuadro de Negro y pruebas de aceptación
Prueba de la unidad revela errores de código todo el tiempo.
Seré honesto. Recientemente comencé a escribir pruebas unitarias, y cuando vuelvo a modificar una antigua DLL que es de mis viejos tiempos, me agacho y escribo pruebas unitarias para obtener una cobertura de código cercana al 100%. Digo "cerca" porque el último porcentaje puede ser difícil de conseguir debido a la forma en que está estructurado el código, que no tiene en mente burlas o pruebas unitarias (esto sucede mucho con las clases o clases abstractas que P/Invocar en código nativo). Y aunque entiendo que la cobertura de código 100% no es lo mismo que el 100% de todas las rutas de ejecución de código, he encontrado que tener las pruebas es una buena forma de saber cuándo estoy haciendo algo que va a romper mucho de cosas.
Para ser sincero, esta es probablemente una de las razones por las que tantos desarrolladores (incluido yo mismo) hemos tardado tanto en adoptar las pruebas unitarias (no entremos todavía en TDD).
No estoy diciendo que cualquiera de estas son razones legítimas, pero que tenía más o menos me pasan por la cabeza, y apuesto a que pasaron algunos de los suyos también:
En primer lugar, hay una pensé en la línea de "Oh, he escrito montañas de código con cero pruebas, y viendo que ya estoy aplastado por esa montaña, posiblemente no tenga tiempo de agregar varias montañas más de código de prueba en la parte superior de eso."
En segundo lugar, a nadie le gusta hablar sobre el hecho de que el ciclo de gestión de código clásico-depuración funciona realmente 'lo suficientemente bueno' cuando estás
En tercer lugar, las pruebas unitarias son más fáciles de apreciar cuando se mantiene el código existente, y si siempre está escribiendo código nuevo, bueno, los beneficios no son inmediatamente obvios. Cuando su trabajo es generar una utilidad y nunca volver a tocarla, un desarrollador puede ver poco valor en la prueba de la unidad porque probablemente no estará trabajando en esa utilidad o en la empresa cuando un programador de mantenimiento (que desea allí fue una prueba unitaria).
En cuarto lugar, las pruebas unitarias son una innovación bastante reciente. (Oh, silencio ... Sé que la idea ha existido por siempre, especialmente en aplicaciones de misión crítica y DoD, pero para el "Joe el fontanero Developer" me gusta? Las pruebas de unidad no se mencionaron en absoluto durante mi toda la carrera de licenciatura de CS en la primera parte de esta década, en 2008, escuché que es un requisito para todos los proyectos desde el nivel 101 en adelante. Visual Studio ni siquiera consiguió un marco de prueba integrado hasta este año, y solo entonces en la edición profesional.) ¿Fue una bendita ignorancia de mi parte? Claro, y creo que mucha gente que codifica porque es su trabajo diario (lo cual está bien) simplemente no lo sabe. Si lo son, entonces saben que deben mantenerse al día, pero cuando se trata de aprender una nueva metodología (particularmente una que implica escribir más código y tomar más tiempo adelantado cuando necesitó esa nueva característica hecha ayer) significa que será rechazado. Esta es la cola larga, y en una década más o menos nuestras charlas sobre pruebas unitarias parecerán tan pintorescas como nuestras murmuraciones sobre programación orientada a objetos que permitan una nueva era de desarrollo durante los años noventa. Diablos, si he comenzó la prueba de la unidad, el final debe estar cerca, porque yo soy generalmente un idiota.
Quinto, probar algunas áreas del código es realmente difícil, y esto me asustó por un tiempo. Colas de eventos multiproceso, representación gráfica y GUI vienen a la mente. Muchos desarrolladores se dan cuenta de esto y piensan "bueno, las pruebas unitarias serían geniales para el código de la biblioteca, pero ¿cuándo fue la última vez que escribí una biblioteca de clase?". Toma un tiempo para venir. Con ese fin, ninguna prueba unitaria no significa necesariamente que haya un mal código.
Finalmente, el nivel de evangelismo que a veces proviene de los defensores de las pruebas unitarias puede ser intimidante y desagradable. En serio, pensé que era un imbécil porque no podía entender cómo burlarme de cierta interfaz y por qué querría. Egoístamente, quería odiar las pruebas unitarias si solo por el hecho de que no todos se callaran al respecto. Sin bala de plata
Por lo tanto, me disculpo por la publicación laberíntica. En resumen:
No he probado la unidad durante mucho tiempo. Ahora lo hago. Las pruebas unitarias son una gran herramienta, especialmente durante el mantenimiento.
Para proyectos existentes, al menos puede ingresar y escribir una prueba que documente una entrada actual y su salida.Cuando cambies ese gran lío de código turbio en el futuro, podrás ver si has alterado esa pequeña instantánea. Esta es también una excelente manera de cambiar la cultura de desarrollo en su empresa.
Let the flames begin! =)
muy útil, pero creo que no estoy de acuerdo contigo cuando dices que el final está cerca de – DanielV
Cuando utilizas la base de datos MongoDB en tu aplicación, creo que Unit Testing sería incluso más útil especialmente para probar las operaciones CRUD de tus entidades porque MongoDB deja que el desarrollador de la aplicación se asegure de mantener la integridad referencial de clave externa. A diferencia de las bases de datos RDMS, MongoDB y muchas otras bases de datos NoSQL dejan la aplicación de asociaciones de datos válidas para el desarrollador de la aplicación. –
Sé por experiencia que cuando escribo código sin pruebas de unidad, me salen algunos problemas que se solucionan, pero cuando escribo las pruebas de unidad raramente escucho problemas. Además, del tiempo dedicado a escribir pruebas unitarias, escribo un código mejor para empezar. Miro los métodos y pienso en las formas en que podrían fallar y los construyo desde el principio para no fallar o al menos para fracasar de una mejor manera.
Pruebas unitarias SON esenciales para escribir un código mejor, pero también lo harán un mejor desarrollador porque VEA las áreas donde las cosas podrían salir mal y las soluciona antes de que pueda realizar las pruebas.
Encuentro que los desarrolladores más nuevos se benefician más de las pruebas unitarias que los mayores que tuvieron que aprender de la escuela de los obstáculos que podrían hacer que algo fallara. Las pruebas unitarias no conducen a un buen diseño, solo conduce a un diseño que es más comprobable. Debe probar su código, pero la forma en que se predican las pruebas unitarias es peligroso. "Te obligará a diseñar mejor tu código", "¿Cómo puedes probar si es correcto?".
Prefiero tener un código estructurado bien escrito que cuando lo lees automáticamente te dice simplemente qué es lo que intenta lograr y cómo lo hace. Las funciones/clases deben ser pequeñas y concisas. Solo deberían tener una responsabilidad. Las pruebas unitarias no protegen contra errores lógicos.
Las pruebas unitarias dan más falsos positivos que cualquier otra cosa, especialmente cuando se escribe un proyecto por primera vez. Un buen diseño triunfa en las pruebas: las pruebas deben ser la etapa de verificación, nada más. Nunca compre en las pruebas viene antes de todo lo demás. En mi experiencia, esta línea de pensamiento favorece la capacidad de prueba a expensas del código extensible (puede estar bien para proyectos desechables o servicios únicos, pero irónicamente las pruebas unitarias no son tan importantes para estos).
See [is-unit-testing-worth-the-effort?] (Http://stackoverflow.com/questions/67299/isunit-testing-worth-the-effort?rq=1) – nawfal