2010-02-02 11 views
5

He estado desarrollando un marco interno que está diseñado con muchos módulos Perl. Todos estos módulos dependen de un único módulo que expone algunas funcionalidades de Win32. Por ej. Los módulos A, B, C, D, etc. dependen de un único módulo Z. Por lo tanto, todos estos módulos se importarán mediante "usar MyFramework :: Z". Todos estos módulos A, B, C, etc. se pueden usar individualmente & no son dependientes de ningún otro módulo de marco.¿Cómo diseño pruebas unitarias para múltiples módulos Perl en la misma distribución?

Ahora, con ese diseño simple en mente, ¿cómo puedo diseñar mis pruebas de unidad. Estoy planeando usar Test :: More para hacer todas las pruebas unitarias. ¿Debo escribir pruebas unitarias individuales para cada módulo? Hay 25 módulos diferentes que pertenecen a este marco. ¿Alguna sugerencia?

+0

Gracias por todas sus sugerencias. – John

Respuesta

6

Las pruebas unitarias para Z deben cubrir la funcionalidad de Win32.

Las pruebas unitarias para A deben cubrir la funcionalidad de A que no está cubierta en Z. Repita para B, C, D, y así sucesivamente.

Si encuentra que C, E y G están haciendo cosas similares y que está escribiendo pruebas unitarias casi idénticos, es decir la señal de refactorizar - extraer los componentes comunes a un nivel superior (por ejemplo, el módulo de CEG) y simplemente deje y pruebe las partes especiales de C, E y G en sus módulos originales.

1

hay varias cosas que puede hacer:

  1. empezar a escribir ellos! ;)
  2. Una prueba por módulo (como sugirió) e intente probar "solo" el código que está probando. (Suena obvio, pero es fácil de empezar a pensar acerca de las interacciones con otros módulos)
  3. puedes ver los ensayos de módulos en CPAN para ejemplos
  4. leer sobre BDD y TDD
2

En general, me gustaría empezar con la implementación prueba la funcionalidad de bajo nivel y mantiene las pruebas de los módulos que están diseñados para ser independientes entre sí en archivos separados.

Si crees que es importante poder probar tu código independientemente del entorno de Win32, crea algún código de módulo (específicamente para las pruebas) que emule la interfaz del módulo específico de Win32. Una declaración package junto con algunas funciones simplificadas puede funcionar bien, dependiendo de lo que realmente haga el módulo real.

Cuestiones relacionadas