¿Cómo probar la unidad?

Question

Básicamente tengo dos preguntas principales:

• ¿Qué es exactamente debe usted prueba de unidad?
• ¿Cómo lo haces?

El problema es que tengo varias aplicaciones que se basan en una conexión de base de datos y/o son aplicaciones de comunicación, lo que significa la mayor parte de los casos de prueba son pruebas de integración (o eso creo).

La mayoría de las clases son bastante simples por sí mismas, pero las que implementan el protocolo de comunicación, que son las que serían útiles para automatizar las pruebas, pueden encajar bien en el modelo de "prueba de unidad".

Otro ejemplo. Desarrollé una estructura de tubería con soporte multiproceso para un patrón consumidor/productor. Cuando un hilo lee la tubería y la encuentra vacía, bloquea hasta que un escritor escribe en la tubería. ¿Debería usar pruebas unitarias para probar esa clase?

¿Cómo se decide qué unidad de prueba?

Editar: Me refiero a pruebas de unidades de escritura para pruebas unitarias automatizadas.

Answer 1

Su unidad prueba unidades de su código. La verdadera pregunta es, ¿qué es exactamente lo que compone una unidad?

En un entorno orientado a objetos, una unidad es una clase. Una clase porque los comportamientos de un objeto varían con el estado del objeto, por lo que probar un método aislado no arrojará los resultados más completos.

Primero debe identificar las invariantes de la clase. Es decir, las cosas que siempre serán ciertas para todas las instancias de la clase. P.ej. en una clase Fraction un invariante puede ser denominador! = 0.

A continuación, debe identificar los contratos de cada método, es decir, las condiciones previas y posteriores de los métodos.

Luego, escribe pruebas para cada condición que pueda surgir. Entonces, para una sola clase, puede terminar con muchos métodos de prueba para probar las diversas condiciones que podría encontrar cada método. En cada prueba, se asegura que las invariantes de la clase se mantienen y el contrato del método nunca se rompe.

En algunos casos, como en el ejemplo que proporcionó, puede ser necesario crear otros objetos en el entorno para probar las condiciones de su clase. En esos casos, puede usar objetos simulados.

Answer 2

Las pruebas unitarias están probando que la unidad completa funciona igual que antes del cambio, con las mejoras realizadas en el cambio. Si está realizando un cambio en una ventana de un módulo, entonces prueba el módulo. Esto es en comparación con una prueba del sistema, que es probar cada módulo. Si su cambio afecta a muchos módulos (no está seguro de cómo está configurado su sistema), entonces debe obtener una prueba del sistema.

Answer 3

Debe abstraer las preocupaciones de su infraestructura (es decir, código que recupera datos de su base de datos, código que presenta archivos de E/S, etc.) para que pueda resguardar esas partes para probar su aplicación. Y luego podrá escribir pruebas dirigidas/específicas contra su código de infraestructura para probarlo.

Se encontrará creando más interfaces (para crear parece dentro de su aplicación), y necesitando utilizar mejores principios de OO (es decir.SOLID) para desarrollar una aplicación que sea más comprobable.

yo estaba en la misma situación de hace un año en el que se encontraba. Y el libro que realmente me ayudó a través de él (junto con algunas manos en la práctica) es The Art of Unit Testing by Roy Osherove

Answer 4

unidades de prueba Las pruebas unitarias (es decir método o función) en aislamiento, en un entorno dedicado y controlado. Cada prueba unitaria crea en su propio entorno instanciando solo las clases necesarias para ejecutar una prueba, poniéndolas en un estado conocido, luego invoca el método que se probará y verifica el resultado. Esta verificación se realiza mediante aserciones sobre el comportamiento del método (en oposición a su implementación).

Es importante realizar la verificación del comportamiento y no de la implementación, ya que esto permite modificar la implementación sin romper las pruebas unitarias y, por lo tanto, utilizar las pruebas unitarias como red de seguridad para la modificación.

Todos los idiomas tienen [al menos] un unit test framework cuya función es ejecutar las pruebas unitarias. Hay dos formas de escribir pruebas unitarias: prueba primero o prueba última.

La prueba primero también se llama Test-Driven Development. Básicamente se necesitan tres pasos:

1. escribir una prueba falla
2. escribir código justo suficiente como para hacerlo pasar
3. refactorizar el código para limpiarlo (eliminar la duplicación ...)

Los defensores de TDD afirman que esto lleva a un código comprobable, mientras que podría ser difícil escribir pruebas unitarias después del hecho, especialmente cuando los métodos hacen varias cosas. Se recomienda seguir el Principio de Responsabilidad Individual.

En cuanto a la estructura de tubería y las comunicaciones ejemplo de protocolo, algunas pautas dicen que a test is not a unit test if:

• Habla a la base de datos
• Se comunica a través de la red
• que toque el sistema de archivos
• ...

Cuando un hilo lee el conducto y encuentra , lo vacía hasta que un escritor escribe en el tubo. ¿Debería usar las pruebas de unidad para probar esa clase?

Me gustaría probar la clase, pero no el método de lectura de bloqueo, ya que supongo que es construir a partir de una llamada de bloqueo a la función read() del sistema operativo.