unit testing - tipos - ¿Realmente estás usando pruebas unitarias?

unit test dotnet (19)

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.

Entonces, ¿usa pruebas unitarias en sus proyectos, o confía en sus habilidades de codificació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.

Con respecto a confiar en mis habilidades de codificación, descubro que mis habilidades de codificación mejoran cuando uso TDD y confío en mis pruebas unitarias para corregirme cuando rompo una prueba. Aprende a usar muchas funciones del lenguaje porque puede realizar un ajuste para probar una suposición.

Después de participar en un par de proyectos que estaban en producción pero que necesitaban nuevas funcionalidades importantes, una de mis conclusiones como líder técnico al iniciar un proyecto es que las pruebas unitarias son obligatorias.

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 se vuelve particularmente cierto cuando un proyecto entra en modo de lucha contra incendios (y no tener pruebas unitarias contribuye a que los proyectos entren también en ese estado): los clientes se ponen malhumorados, han perdido la fe en el proyecto, pocas cosas peores que ser el pobre tratando de obtener la próxima solución sin introducir una pila completa de errores de regresión, y ni siquiera tener pruebas unitarias.

Esas situaciones pueden evitarse tan fácilmente o al menos atenuarse 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 las pruebas unitarias y he dedicado mucho tiempo a solucionar los problemas causados por otros desarrolladores que confiaron en sus habilidades de codificación.

El uso de pruebas unitarias es una habilidad de codificación.

Encuentro 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í: ¿Vale la pena el esfuerzo de las pruebas unitarias?

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 sobre 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).

Es probable que sus clientes ahorren dinero en general si se llevaron 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.

Escribir y ejecutar pruebas unitarias es parte de un proceso de codificación saludable, no es una adición que el cliente debería tener la opción de pagar o no pagar.

La estrategia de prueba es un problema de codificación como cualquier otro: qué estructuras de datos usar, convenciones de nombres variables, estándares de comentarios, etc.

Estoy de acuerdo con Ken en que las pruebas unitarias son parte del desarrollo de software.

Acerca de la pregunta del costo, es verdad que escribir el código más la prueba de la unidad 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) Desarrollo basado en pruebas , finaliza con " código limpio que funciona ". Cuando solo escribes el código, entonces tienes que hacerlo funcionar, lo que puede ser largo y doloroso.

Otro beneficio 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 sea posible. Escribo pruebas unitarias para todo el código nuevo y me esfuerzo por obtener el código heredado.

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 la integración continua , las pruebas de regresión serán automatizadas y constantemente informadas.

Las pruebas unitarias no pueden ser una idea de último momento, es y debe ser algo que tenga en cuenta 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.

Las pruebas unitarias son una parte esencial del desarrollo, y (he descubierto) realmente reducirán el tiempo hasta la finalización de un proyecto mientras se mejora la calidad general, especialmente cuando se realiza en un entorno TDD.

Me gusta la analogía de Bob Martin: imagina que eres 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 funciona como debería", y sé que la mejor manera de hacerlo es usar TDD.

Mi compañía fabrica componentes de sistemas para varias compañías en la industria aeroespacial. La FAA requiere Condición modificada / Cobertura de decisión para el software de seguridad del nivel A de seguridad crítica ( DO-178-B ). Para la verificación lo hacemos (nuevamente desde DO-178-B):

Por lo general, se requiere el análisis de todos los códigos y la rastreabilidad de las pruebas y los resultados a todos los requisitos (dependiendo del nivel del software).

Este proceso generalmente también involucra:

Herramientas de prueba basadas en los requisitos
Herramientas de analizador de cobertura de código
Otros nombres para las pruebas realizadas en este proceso pueden ser:
Examen de la unidad
Pruebas de integración
Caja negra y prueba de aceptación

Las pruebas unitarias revelan errores de código todo el tiempo.

Otro recordatorio muy útil de por qué quieres probar la unidad donde sea que acabes de aparecer en esta publicación: Las 12 Razones Principales para Escribir Pruebas de Unidad 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 a través de cada iteración. Necesito ser más sistemático, yo mismo. Estoy imprimiendo esa lista ahora mismo.

Sé por experiencia que cuando escribo código sin pruebas unitarias, me salen algunos problemas que se solucionan, pero cuando escribo las pruebas unitarias raramente escucho los 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.

Las 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.

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) han tardado tanto en adoptar pruebas unitarias (no entremos todavía a TDD).

No estoy diciendo que ninguno de estos sean motivos legítimos, pero más o menos pasaron por mi cabeza, y apuesto a que pasaron por algunos de los suyos también:

Primero, hay un pensamiento como "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 prueba código encima ".
En segundo lugar, a nadie le gusta hablar sobre el hecho de que el clásico ciclo de ejecución de código funciona realmente "lo suficientemente bueno" cuando estás
- escribiendo un nuevo código que no altera el comportamiento del código anterior
- trabajando en un proyecto de software relativamente pequeño o en una utilidad desechable
- el único desarrollador en un proyecto (puedes mantener la mayor parte en tu cabeza, hasta cierto punto)
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 un 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 los tipos "Joe el ~~fontanero~~ " como yo). Las pruebas unitarias no se mencionaron en absoluto durante toda mi CS carrera de pregrado 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 obtuvo un marco de prueba incorporado hasta este año, e incluso entonces solo en el profesional edición.) ¿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 están, 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 por adelantado cuando se necesita 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 comencé a realizar pruebas unitarias, el final debe estar cerca, porque generalmente soy un idiota.
Quinto, probar algunas áreas de 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 desalentador. 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 solo por el hecho de que no todos se callarían al respecto . Sin bala de plata

Entonces, disculpas por la publicación en divagaciones. En resumen:

No hice una prueba unitaria 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.

¡Deje que las llamas comienzen! =)

Soy un gran admirador de las pruebas unitarias, principalmente porque es completamente adictivo: el ciclo "prueba de código: ve un reloj de barras rojas horrible, ve una barra preciosa verde" en JUnit realmente hace que las endorfinas bombeen.

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í.

Yo hago la prueba unitaria. Actualmente estoy construyendo un motor de validación de restricciones y mis clientes lo quieren a prueba de balas. Bueno, sin una prueba unitaria, moriría de estrés ...

Entonces sí, ¡lo uso!