Preparación de las pruebas de unidad: ¿Qué es importante tener en cuenta cuando se trabaja en una arquitectura de software? [cerrado]

Question

Vamos a decir que estoy empezando un nuevo proyecto, la calidad es una prioridad.

Mi plan es hacer una amplia unidad de pruebas, lo que es importante a tener en cuenta cuando estoy trabajando en la arquitectura para facilitar y dar más poder a las pruebas unitarias?

editar : He leído un artículo hace unos momentos (no puedo encontrar ahora) hablando de cómo desacoplar el código de instancias de clases de comportamientos podrían ser útiles cuando la unidad de pruebas. Ese es el tipo de consejos de diseño que estoy buscando aquí.

Answer 1

Facilidad de prueba viene a través de ser capaz de reemplazar ya que muchas de las dependencias que su método tiene con el código de prueba (burla, falsificaciones, etc.) La forma en que actualmente se recomienda para lograr esto es a través de la inversión de la dependencia, también conocido como el Principio de Hollywood: "Don 't nos llaman, le llamaremos ". En otras palabras, el código debe "pedir las cosas, no hay que buscar cosas."

Una vez que usted comienza a pensar de esta manera encontrará código puede fácilmente tener dependencias en muchas cosas. no solamente tiene dependencias en otros objetos, pero las bases de datos, archivos, variables de entorno, las API del sistema operativo, globales, únicos, etc. Al adherirse a una arquitectura bien, reducir al mínimo la mayor parte de estas dependencias, proporcionándoles a través de las capas apropiadas. Así que cuando llega el momento de la prueba, no se necesita una base de datos completa de trabajo de datos de prueba, sólo tiene que reemplazar el objeto de datos con un objeto de datos simulada.

Esto también significa que tiene cuidadosamente a ordenar la construcción de su objeto a partir de su ejecución del objeto. La "nueva" declaración colocada en un constructor genera una dependencia que es muy difícil de reemplazar con un simulacro de prueba. Es mejor pasar esas dependencias en medio de argumentos de constructor.

Además, tenga la Ley de Demeter en mente. No cavar más de una capa profunda en un objeto, o de lo contrario se crea dependencias ocultas. Llamando Flintstones.Wilma.addChild (guijarros); mediante lo que pensaba que era una dependencia de "Los Picapiedra" realmente es una dependencia de ambos "Picapiedra" y "Wilma".

Answer 2

Asegúrese de que el código es comprobable por lo que es altamente cohesivo, humilde desacoplado. Y asegúrese de que sabe cómo utilizar las herramientas de burlarse burlarse de las dependencias durante las pruebas unitarias.

Te recomiendo que se familiarice con el SÓLIDO principio , de modo que usted puede escribir un código más comprobable.

Answer 3

También puede ser que desee echa un vistazo a estas dos preguntas SO:

• ensayo Unidad Adopción
• Lo que debería ser una Unidad

Answer 4

Algunos pensamientos al azar:

• definir sus interfaces: desacoplar los módulos funcionales entre sí, y decidir cómo van a comunicarse entre sí. La interfaz es el “contrato” entre los desarrolladores de diferentes módulos. Entonces, si sus pruebas operan en las interfaces, que está asegurando que los equipos pueden tratar los módulos de cada uno como cajas negras, y por lo tanto trabajar de forma independiente.

• crear y probar al menos la funcionalidad básica de la interfaz de usuario en primer lugar. Una vez que su proyecto puede “hablar” con usted, se puede saber lo que funciona y lo que no lo es ... pero sólo si no está mintiendo. (Bonus:. Si los desarrolladores no tienen más remedio que utilizar la interfaz de usuario, podrás identificar rápidamente cualquier deficiencia en la facilidad de uso, flujo de trabajo, etc. )

• Prueba a nivel práctico más bajo:. más seguro se encuentra que el pequeño piezas de trabajo, más fácil será para combinarlos en un trabajo conjunto

• Escribir al menos una prueba para cada función, en base a las especificaciones, antes de empezar a programar. Después de todo, las características son la razón por la que sus clientes van a comprar su producto. Asegúrese de que está diseñado para hacer lo que se supone que tiene que hacer!

• No se queden satisfechos cuando se hace lo que se supone que debe hacer; asegurarse de que no hace lo que se no se supone que haga! Aliméntela malos datos, utilice de una manera ilógica, desconecte el cable de red durante la transferencia de datos , ejecutarlo junto con aplicaciones en conflicto. Sus clientes.

Buena suerte!

Answer 5

Sus pruebas solamente nunca será tan bueno como sus requisitos. Pueden existir requisitos que subir con el principio de una sola vez, pueden ser requisitos que usted sube con uno a la vez a medida que agrega características, o que puede haber requisitos que usted sube con después de que lo envía y comenzar personas informar de un barco de carga de errores, pero no se puede escribir una prueba buena si nadie puede o quiere documentar exactamente lo que se supone que lo que hay que hacer.