Probando programas completos.mejores prácticas

Question

Actualmente estoy desarrollando una biblioteca y un conjunto de programas usando esta biblioteca, en Python.Las pruebas unitarias dictan que importo cada módulo de la biblioteca y pruebo las clases y rutinas que contiene.Ningún problema con eso.Tengo un directorio de prueba separado que contiene todas mis pruebas e importo los módulos de la biblioteca, que ejecuto mientras desarrollo.

Sin embargo, a la hora de probar los programas, la cosa cambia.Para ser probados, los programas deben ejecutarse en su totalidad.Los programas suponen que encuentran la biblioteca instalada (lo que en realidad podría ser el caso, aunque sea incorrecto, si instalé una versión anterior en mi máquina, lo que agregaría más problemas).Por el momento, mis programas se ejecutan mediante un conjunto de pruebas con una definición de PYTHONPATH que realizo manualmente, antes de la implementación (IOW, no realizo la instalación), pero no creo que lo esté haciendo bien.Siento que, en general, se debe probar la funcionalidad de un programa cuando está completamente implementado, pero esto significaría que tengo que instalarlo cada vez que quiera realizar pruebas funcionales.

¿Cuál es su experiencia y sugerencias con respecto a las pruebas funcionales de programas completos?¿Lo hace antes o después del despliegue y cómo?

Gracias

Tenga en cuenta que no incluyo la etiqueta de Python a propósito.Aunque mi problema es específico de Python y preferiría respuestas relacionadas con Python, creo que la contribución también puede provenir de expertos en otros idiomas.

---

Editar:Como se informó en un comentario, el hecho es que mi programa, cuando está instalado, tiene que importar módulos cuya ruta solo se puede encontrar cuando se implementa (descargo e instalo las dependencias sobre la marcha, no están instaladas en mi máquina).No puedo manipular sys.path desde la prueba, porque eso implicaría que modifico el sys.path de un programa (mi ejecutable) desde otro programa (el conjunto de pruebas, que se ejecuta y genera una llamada al sistema()).

En otras palabras, la única forma que tengo de probar el programa sin implementarlo es ejecutar el programa con PYTHONPATH configurado en el directorio que contiene los departamentos y la biblioteca que usa el programa instalado por el script make (que, como dije, descarga, compila e "instala" todo en un directorio temporal).

En el momento de la implementación, los departamentos y los ejecutables se empaquetan juntos en una estructura similar a un "paquete OSX", que es completamente ejecutable y reubicable.

Editar:

Agregué una recompensa de 150 para ver si puedo obtener un poco más de comentarios.

Editar:

Aprecié todas las respuestas y las voté todas.La elección ha sido una decisión difícil para mí, pero LudoMC me recordó el enfoque de prueba del modelo V que estudié hace mucho tiempo.Gracias a todos por las muy buenas respuestas.

Answer 1

En nuestra empresa, estamos utilizando un V-Modelo bastante utilizado comúnmente como proceso de desarrollo, donde las pruebas unitarias se realizan dentro de la fase de implementación, las pruebas de integración se realizan en contra de la fase de la arquitectura / diseño, y las pruebas del sistema en contra de la fase de requisitos.

Así pues, en su caso, por lo que entiendo, quieres probar la aplicación en su conjunto, a nivel funcional. Por lo que tiene que hacer frente a las necesidades.

Por lo tanto, se necesita un documento de requerimientos, ya sea un escenario de texto completo o diagrama de casos (mejor) que cubre un uso UML (lo ideal es ampliamente) los casos de uso de la aplicación (por lo general uno de la primera fase a alcanzar). A continuación, tiene que escribir casos de prueba que abarcan todos los casos de uso y pasar estos casos de prueba. Se puede hacer a través de pruebas manual o automática con las herramientas conocidas (y bastante caro).

Para la cuando , que normalmente hacemos estas pruebas del sistema después del despliegue (equipo de pruebas está utilizando el programa de instalación proporcionado por el equipo de desarrollo), ya que también probamos el instalador en sí, donde las pruebas de integración son antes o después del despliegue, dependiendo del caso.

En su caso, si el instalador esté libre de errores, y que está 100% seguro de que las pruebas antes del despliegue utilizando la variable de PYTHONPATH nunca traerá un error una vez desplegado, entonces usted puede elegir para poner a prueba antes del despliegue. Es de gestión del riesgo puro y es su decisión, porque eres el que sabe la mejor los pros y los contras de este para sus aplicaciones. (Personnaly, no veo por qué los insectos no pueden existir allí, están por todas partes :-))

Espero que ayude y no estoy fuera de tema

Answer 2

Bueno, la prueba (automatizado) es siempre una solución de compromiso, por lo que no hay una sola manera correcta de hacerlo.

Pero sí, lo ideal es que hacer una instalación completa de forma automática / despliegue de su programa antes de ejecutar las pruebas. De esa manera también se prueba su instalador.

Tal vez usted puede escribir un envoltorio de instalación que automatiza esto para usted. Si es demasiado trabajo, es probable que pueda también ejecutar la prueba de funcionamiento dentro de un despliegue que se ha creado de forma manual.

Como solución de compromiso, que podría tener su ejecución de la instalación una sola vez al comienzo de una ejecución de prueba, a continuación, ejecutar todas las pruebas de funcionamiento w / o reinstalación, para hacer las pruebas se ejecutan más rápido.

Answer 3

Pruebe todo lo que pueda dentro de lo razonable.Si sería genial probar algo pero requiere mucho esfuerzo, entonces no lo pruebes...todavía.Solo cuando descubra que tiene problemas en ese lugar una y otra vez, dedique el esfuerzo.Nunca asuma de antemano dónde estarán los problemas (excepto cuando saber antes de tiempo...pero entonces, conocimiento no es asumiendo!).

Entonces, si la instalación del programa rara vez causa problemas, no intentes probarlo.Si su implementación es frágil, tal vez escriba una prueba que verifique que el archivo de instalación sea completo en lugar de intentar instalar:No estás probando el sistema. instalador, estás probando tu paquete.

Answer 4

Nos hemos enfrentado 'un problema similar acerca de la implementación, y estamos usando virtualenv para probar las implementaciones. Especialmente con la opción --no-site-packages, que es como tener una instalación prístina, y sin ensuciar con PYTHONPATH más allá de una solución de 3 ª parte bien probado. Y sólo para estar seguro, corremos la cosa entera, virtualenv y todo, en una máquina virtual nueva.

por cierto, un truco útil con virtualenvs es ./setup.py develop.

(De un oficial a otro ...)

Answer 5

Para asegurarse de que debe probar su programa en los escenarios posteriores a la implementación del todo correctos.

Es posible considerar la integración de una capacidad de auto-prueba de la derecha en su código de producción, y proporcionar un mecanismo para ejecutarlo en la demanda. Tal vez tenga sentido para ejecutar la autocomprobación sólo durante su propia prueba del sistema, pero su instalador podría funcionar como un paso final, los usuarios podrían ejecutar desde un elemento de menú, o que incluso podría tener una "prueba de encendido auto "en el inicio.

Hay un montón de técnicas para hacer esto. Si implementa un servicio web, la autocomprobación se puede invocar a través de un URI administrativo que realizar peticiones HTTP sobre sí misma para verificar que funcionen. auto-pruebas estáticas son probablemente todo lo que necesita, pero también se puede cargar y ejecutar scripts de prueba dinámica. Para esto último, puede utilizar los servicios de interpretación de su lenguaje, o si no hay ninguno, puede incrustar un intérprete en su software (por ejemplo, TCL para C / C ++ y Rhino para Java) o escribir su propio mini-intérprete.

Answer 6

Hacer pruebas funcionales tiene sus limitaciones, ya que no puede generalmente simular una persona que utiliza la interfaz gráfica de usuario, y no probar las acciones anormales que un usuario puede hacer, ya que sólo pueden hacer clic o escriba cosas que no tendrían sentido.

Lo mejor que puede hacer es tener tan poco lógica de negocio en la vista parte de la aplicación, a continuación, puede mejor prueba, como se puede comprobar los controladores de abajo, o si lo tienes, los servicios de tu web / Descanso en hacia abajo.

Es necesario tratar de ser lo más completa en la prueba, la prueba de los dos casos positivos y negativos, para asegurarse de que sabe cómo la aplicación funcionará independientemente de lo que se envía por el usuario.

He encontrado NUnit y JUnit ser útil para hacer pruebas de esta manera, pero para las pruebas funcionales, en última instancia, que terminan recurriendo a ir justo a través de un script de prueba manual, en la mayoría de los casos. Me tienden a tener una forma de ejecutar todas las pruebas para la aplicación mediante el uso de algo así como la hormiga, para ayudar a asegurarse de que tanto puede ser probado como sea posible, y luego me iba a casa, ya que el conjunto completo de pruebas podría llevar mucho tiempo para funcionar.