"Cualquier cosa puede salir mal, saldrá mal" - La Ley de Murphy. ¿Entonces es necesario probar todos los casos condicionales, de excepción? [cerrado]

7

Si "Cualquier cosa puede salir mal, saldrá mal" es cierto, debemos probar todos los condicionales y casos excepcionales en mi código.

Pero a veces es difícil encontrarlos, ya que muchos de ellos son casos de esquina, que son difíciles de probar. ¿Cómo puedo encontrar mejor los casos de esquina o evitar el problema?

    
pregunta panda 03.09.2011 - 08:04

6 respuestas

2

¡Sí! Cada bloque de código debe ser probado. Pero, ¿cómo lo pruebas? Por Unit Testing en primer lugar,

bueno, para permitir que el código sea verificable, es otra teoría, es un tipo de técnica de programación. No puedes dejar que tu código se convierta en olor.

  1. Pruebe su código parte por parte por función.
  2. Su función debe ser específica, un propósito, simple, no compleja.
    p.ej. no haga una variable global en su función, de lo contrario (no verificable)
  3. Su función debe ser comprensible.
  4. Su función es un acoplamiento flexible, menos dependencia, para que pueda probarla fácilmente. etc.etc ....

Una vez que se haya mejorado el estilo de su código, sus casos de prueba, casos de esquina serían fáciles de probar.

Aquí hay un buen artículo sobre cómo hacer que su código deje de oler. Espero que ayude.

    
respondido por el Kit Ho 03.09.2011 - 10:40
9

Considere el análisis de cobertura de código . En mi experiencia, fue una forma bastante eficiente de descubrir casos de uso no probados.

Cuando las pruebas ya tienen una alta cobertura de código, usar este enfoque para descubrir agujeros también puede ser divertido, ya que los casos restantes resultan poco obvios (o, lo que es más interesante, podrían corresponder a errores) en la especificación).

  • Simplemente no asuma que el análisis de cobertura garantizará cubrir todos los casos relevantes. Por ejemplo, no lo protegerá de los problemas de característica faltante o concurrencia .

Lo que hay que tener en cuenta es que puede ser difícil profundizar en todos los casos posibles. Imagine una aplicación diseñada para mostrar "Hello World" si, y solo si es jueves y llueve, para probarlo, ¿tendría que esperar hasta el jueves cuando llueve? o simulacro las condiciones necesarias. Eso puede ser un esfuerzo excesivo para justificar los riesgos que evitaría al tenerlo cubierto en las pruebas.

Otra cosa a considerar es cuánto tiempo lleva la prueba. Si le toma un año probar su aplicación por completo, es mejor que deje esa idea (a menos que esté en un producto de misión crítica)

    
respondido por el gnat 03.09.2011 - 10:00
3

Encuentro esto muy cierto. A veces tiendo a ser perezoso y no pruebo ciertas líneas de código, pero casi nunca falla en volver y pegarme.

Si estás escribiendo código OO. Aquí están las entradas basadas en mi aprendizaje.

  • Usa Razor Occam . Esa es la forma más sencilla de implementarlo.
  • Divida todo lo que se puede dividir en varias clases o mixins hasta que vea que cada clase o mixin está haciendo exactamente una cosa. Eso es respeto SRP .
  • Para cada mezcla / clase, escriba al menos un caso de prueba que inicialmente cubra cada función.
  • Si está utilizando una biblioteca de terceros, vea si hay posibilidades de que esas funciones puedan generar resultados inesperados de la documentación.
  • Ahora mire si / for / while / case y construcciones similares para ver si eso está cubierto en su caso de prueba. Si no escribe más casos de prueba.
  • Compruebe si alguna línea puede fallar debido a elementos como NullPointerException o el tipo de error no definido por el objeto. Normalmente, las líneas después de algún tipo de creación de objetos o cosas que dependen del uso de la biblioteca para establecer su objeto.
  • Use las pruebas de caja negra, en las que prueba cada función si el público está disponible o no. La mayoría de los marcos de prueba creen que las interfaces públicas de prueba funcionarán (pruebas de caja blanca) y algunos idiomas no le darán acceso a interfaces privadas. En estas situaciones, intente probar las funciones privadas a través de funciones públicas.
  • Use algún tipo de herramientas automatizadas que puedan probar la cobertura del código.

Incluso después de esto, habrá algunos escenarios que uno no puede probar fácilmente, especialmente las cosas relacionadas con el entorno. Puede obtener el código revisado por un programador experimentado o ejecutar sus casos de prueba en todos los entornos posibles.

Uno nunca puede estar completamente seguro de que todos los casos están cubiertos. Si ha pasado mucho tiempo con el código mientras está desarrollado, ganará confianza en él. Una vez que tengas suficiente confianza, libéralo valientemente. Las cosas volverán, ya que habrías leído tu código 100 veces, puedes arreglar las cosas muy rápido y podrás imaginar que otros lugares sucederán. Para cada error que vuelva, cúbralo con casos de prueba.

    
respondido por el arunmur 03.09.2011 - 10:16
1

Si todos supieran cómo dar cuenta de todo , básicamente habría una versión de software, no se necesitaría mantenimiento, no se requerirían probadores, etc. No puede seguir un conjunto de pautas que le darán una respuesta mágica en blanco y negro porque la lista de elementos a probar se basa en un componente de múltiples variables (código).

Lo mejor que puedes hacer es aprender . Cometerás errores y te olvidarás de hacer cosas; Haz un esfuerzo consciente para no cometer el mismo error dos veces. Si puede hacer esto, probablemente sea mejor que el ingeniero de software promedio.

    
respondido por el Jonathan Khoo 03.09.2011 - 09:31
1

Quizá

No puede explicar todos los casos excepcionales a menos que tenga un montón de tiempo y dinero. Cuantas más interconexiones haya en un sistema de software, más complejo será y más se necesitarán para cubrir incluso los casos de prueba estándar. Ni siquiera estamos hablando necesariamente del código que escribiste. Recuerde que siempre que su software no esté funcionando sin memoria (eso no crece) tendrá muchos más casos de excepción. El acceso a la red, el disco, la pantalla y cualquier otro dispositivo puede causar una excepción. Crecer la memoria puede causar una excepción. En algunos casos, incluso detectar que el software se detuvo incorrectamente puede ser un caso de excepción. La pregunta es si realmente necesita cubrir cada caso de excepción.

Si estás trabajando en un software en el que las vidas están en juego, literalmente. Entonces sí, es probable que necesite al menos considerar todos los casos de excepción. Software de cirugía, software Space Shuttle, software de sistema de armas, etc. En cada uno de estos casos, a menudo hay un análisis explícito de cuáles son todas las excepciones y si es necesario cubrirlas. Este tipo de proyectos a menudo terminan gastando mucho más tiempo y dinero para cubrir estos casos. Ese es el costo de cubrir "todos" los casos de excepción.

No

¿Estás trabajando en un software de redes sociales? Una aplicación de Facebook, una aplicación de iPhone, algún sitio para entusiastas de las motocicletas, etc. Este tipo de software no suele justificar el tipo de consideración que mencioné anteriormente. Por lo general, hay un costo para llegar tarde al mercado, y cubrir incluso algunos de los casos excepcionales puede ser prohibitivamente costoso. A menudo, esta puede ser una decisión que tendrá implicaciones comerciales, especialmente en un inicio. ¿Cubre todos esos casos y saca a su empresa del negocio, o pierde una gran parte de los ingresos?

Depende

Entonces la respuesta es "depende". Depende de las necesidades de la empresa, el costo de esas excepciones, el costo del tiempo extra y el esfuerzo requerido para protegerse de esas excepciones y el tiempo involucrado.

Idealmente

Lo ideal es que hagas balance. Usar prácticas como pruebas automatizadas para obtener al menos la mayor cobertura posible en su código sin demasiado costo en tiempo o dinero. Puede utilizar prácticas como pruebas de unidad, pruebas funcionales, pruebas fuzz, etc .; para que el software no sea demasiado defectuoso, que sea fácil de mantener y extender, y así puedas verlo y sentirte orgulloso de lo que escribiste.

    
respondido por el dietbuddha 03.09.2011 - 19:15
0

Lo más importante es que sucederán cosas que no has anticipado y, por lo tanto, no se han codificado.

Es muy importante que tu programa maneje esto correctamente. Debe elegir si "algo inesperado sucedió" es lo suficientemente malo como para que el programa se cierre con gracia inmediatamente para una inspección manual o qué otro procedimiento podría ser correcto.

Personalmente he descubierto que el enfoque de "fallar rápido" es la mejor manera de obtener un buen comportamiento del programa después de algunas iteraciones.

    
respondido por el user1249 03.09.2011 - 10:43

Lea otras preguntas en las etiquetas