Un nuevo nombre para pruebas unitarias [cerrado]

9

Nunca me gustaron las pruebas unitarias. Siempre pensé que aumentaba la cantidad de trabajo que tenía que hacer.
Resulta que eso solo es cierto en términos de la cantidad real de líneas de código que escribe y, además, esto se compensa por completo con el aumento en la cantidad de líneas de código útil que puede escribir en una hora con pruebas y desarrollo impulsado por pruebas.

Ahora me encantan las pruebas unitarias, ya que me permiten escribir código útil, ¡que a menudo funciona la primera vez! (toco madera)

He descubierto que las personas son reacias a hacer pruebas unitarias o comenzar un proyecto con desarrollo basado en pruebas si están bajo plazos estrictos o en un entorno donde otros no lo hacen, por lo que no lo hacen. Un poco como, una negativa cultural a intentarlo.

Creo que una de las cosas más poderosas sobre las pruebas unitarias es la confianza que te da para emprender la refactorización. También da nuevas esperanzas, que puedo darle mi código a otra persona para que lo refactorice / mejore, y si las pruebas de mi unidad aún funcionan, puedo usar la nueva versión de la biblioteca que modificaron, prácticamente, sin temor.

Es este último aspecto de las pruebas unitarias que creo que necesita un nuevo nombre. La prueba unitaria se parece más a un contrato de lo que este código debe hacer ahora y en el futuro.
Cuando escucho la palabra prueba, pienso en ratones en jaulas, con múltiples experimentos realizados para ver la efectividad de un compuesto. Esto no es lo que son las pruebas unitarias, no estamos probando un código diferente para ver cuál es el enfoque más afectivo, estamos definiendo qué resultados esperamos con qué entradas. En el ejemplo de los ratones, las pruebas unitarias se parecen más a las definiciones de cómo funcionará el universo en comparación con los experimentos realizados en los ratones.

¿Estoy en crack o alguien más ve esta negativa a hacer pruebas y piensan que es una razón similar por la que no quieren hacerlo?
¿Qué razones dan ustedes / otros para no realizar la prueba?
¿Cuáles crees que son sus motivaciones en las pruebas unitarias?

Y como un nuevo nombre para las pruebas unitarias que podrían superar algunas de las objeciones, ¿qué tal jContract? (Un poco centrado en Java, lo sé :), o contratos de unidad?

tdd unit-testing

— Será
fuente

14

¿Lo que hay en un nombre? lo que llamamos una rosa con cualquier otro nombre olería tan dulce; - Shakespeare, Romeo y Julieta, c.1600

— Steven A. Lowe

8

No sé si estás en crack. Nunca he intentado crack, o ser tú.

— Tim Post

1

Creo que las ideas se unen a las palabras principalmente debido a las ideas y actitudes asociadas a ellas, no a las palabras. Recuerdo haber descubierto que la Sociedad de Plásticos había cambiado su nombre a Ámbito, porque el nombre estaba asociado con prejuicios. Lo recuerdo porque explicaba por qué había escuchado a los niños llamándose unos a otros "vacíos" ese mismo día. Si desea cambiar la actitud, concéntrese en la actitud, no en el nombre; obsesionarse con el nombre es solo una pérdida de tiempo.

— Steve314

2

Diseño por contrato: en.wikipedia.org/wiki/Design_by_contract Tiene una conotación específica, y las pruebas unitarias no lo son. Si veo algo con Contract en el nombre, eso (e interfaces) es lo que mi cerebro asocia con él.

— Berin Loritsch

@ Steve314 Scopey. Gusta. :) Creo que en este caso, la prueba de palabras ya está definida y, por lo tanto, cambiar el nombre de las pruebas unitarias a un término indefinido sería mejor. El contrato no puede ser debido a la mencionada 'interfaz'. ¿Qué tal 'crear mejores programas más rápido' o CBPF?

— Will

5

¿Estoy en crack o alguien más ve esta negativa a hacer pruebas y piensan que es una razón similar por la que no quieren hacerlo?

La palabra prueba en pruebas unitarias hace que la gente piense que se trata de pruebas de integración o pruebas de interfaz de usuario porque ese es el único tipo de prueba que han realizado. Es como poner java en javascript.

Cuando algo tiene un mal nombre y afecta el pensamiento de las personas al respecto, se denomina error de encuadre. Los errores de encuadre tienden a ser superficiales: las personas son inteligentes y pueden ver a través de todo tipo de malos nombres, malas metáforas.

¿Qué razones dan ustedes / otros para no realizar la prueba?

Dependencias que son difíciles de burlar / falsificar /

¿Cuáles crees que son sus motivaciones en no pruebas unitarias?

Las pruebas unitarias tienen un recuento de conceptos modesto y es necesario realizar una cantidad de trabajo no trivial antes de dejar de escribir pruebas unitarias malas y comenzar a escribir las buenas. A medida que las personas mejoren al explicar qué son las pruebas unitarias, la adopción aumentará. En mi experiencia, las pruebas unitarias tienen un efecto casi mágico en la productividad y la calidad del código. Pero no comenzó de esa manera. Originalmente utilicé marcos de prueba de unidad como una forma conveniente de escribir pruebas de integración.

— MatthewMartin
fuente

Grandes puntos Tratar de explicar por qué 'probarías' un método get simple es difícil, explicando por qué es contractualmente importante para la estabilidad de todo el resto de tu código que el método get siempre devuelva lo que esperas es un argumento más fácil de hacer

— Will

3

El concepto de cambio de nombre ya ha sido proferido. Se llama Desarrollo Conducido por el Comportamiento . Los chicos que se le ocurrieron eso notaron muchos de los mismos argumentos más el ajuste antinatural para probar algo que aún no se ha creado. En cambio, su concepto es escribir una especificación ejecutable (que es de lo que realmente se trata TDD).

He notado el mismo retroceso. También he notado que varias personas simplemente no saben cómo escribir pruebas unitarias. Carecen de las disciplinas del proceso científico, y simplemente usan el marco de prueba de la unidad como una forma de conectar todo y comenzar el depurador. En resumen, no están realmente mejorando el uso de su tiempo. No puedo decir cuántas pruebas unitarias que he visto que tenían varias decenas de líneas de largo (más de 30 líneas) y no una sola declaración de afirmación. Cuando veo eso, sé que es hora de trabajar con el desarrollador y enseñarles qué es una afirmación y cómo escribir pruebas unitarias que realmente prueben.

— Berin Loritsch
fuente

2

La especificación ejecutable probablemente sea anterior a TDD / BDD / Agile / XP. Puede ser tan antiguo como CMMI. Solía ser una moda con UML cuando la gente pensaba que UML es el lenguaje para escribir ES.

— rwong

BDD, como TDD, es un enfoque de prueba, no un tipo de prueba (funcional v integración v unidad v aceptación). El autor pregunta específicamente sobre un "mejor" nombre para las pruebas unitarias.

— ybakos

0

Los contratos se denominan "interfaces" en la mayoría de los casos aquí. Tener pruebas unitarias no garantiza los contratos per se, ya que también puede cambiar las pruebas, por lo que en realidad no sabe que puede usar la nueva versión de la biblioteca solo porque la biblioteca está probada. También debe probar el código que usa la biblioteca. Eso no es diferente de cualquier otra prueba unitaria, por lo que no veo por qué eso necesitaría un nuevo nombre.

Creo, como usted, que la mayoría de las personas reacias a hacer pruebas lo hacen porque piensan que es más trabajo y no sirve.

— Lennart Regebro
fuente

0

Te diré por qué no me gusta TDD: no es porque no pueda ver el valor en él o no reconozca los beneficios de un conjunto de pruebas que puedo ejecutar para verificar todo mi código después de cada modificación.

Es porque no lo necesito. Soy un desarrollador bastante antiguo, cuando era un muchacho no teníamos depuradores integrados sofisticados con editar y continuar escribiendo código, y una compilación podía llevar bastante tiempo, así que tuvimos que obtener cosas bien, desde el principio. Dada tal capacitación, realmente no veo que escribir una carga de pruebas unitarias me haga más productivo o que mi código esté más libre de errores.

Pruebo mi código, pero como siempre lo he hecho, esto ha estado en todo el asunto en lugar de las piezas individuales. Entonces, tal vez tengo 'pruebas unitarias', pero son bastante más gruesas.

Entonces esa es mi razón. No puedo ver la necesidad de que lo haga. El código que produzco es lo suficientemente bueno y, si ese es el caso, ¿por qué debería cambiar mis procesos para arreglar algo que no está roto?

— gbjbaanb
fuente

Debes escribir un código muy simple entonces. La cantidad de estados alcanzables en la mayoría de los sistemas modernos significa que realizar pruebas de extremo a extremo tomaría toda la vida del universo: probar dos piezas cada una con 4 bits de estado requiere 16 casos para probar cada una, o 32 casos de prueba en total; hecho en un sistema de extremo a extremo proporciona 8 bits de estado o 256 casos de prueba para cubrir todos los estados. Personalmente, prefiero hacer 1/8 del trabajo.

— Pete Kirkham

1

@PeteKirkham el corolario de eso es que necesita escribir una gran cantidad de pruebas unitarias y luego también escribir las pruebas de integración para asegurarse de que la unidad aún funcione entre sí. Los lugares donde trabajé que eran muy aficionados a las pruebas unitarias pasaron tanto tiempo escribiéndolos (y manteniéndolos) que empequeñecieron la base de código, y la cantidad de trabajo que hicieron fue muy pequeña en comparación con lo que logré fuera de ese entorno. Nada es una bala mágica, recomiendo tratar de encontrar un enfoque más pragmático que les brinde cobertura de prueba de los bits importantes y al mismo tiempo produzca algo.

— gbjbaanb