Creación de datos falsos para pruebas unitarias

Question

Me considero todavía bastante nuevo en la escena TDD. Pero descubro que no importa qué método use (simulando el marco o copiando mis propios objetos) me parece que tengo que escribir mucho código para crear datos falsos. Me gusta la idea de cargar objetos para crear una base de datos en memoria. Pero lo que no me gusta es llenar mis pruebas con un montón de código con el único propósito de crear datos falsos. Este es especialmente el caso cuando los datos deben tener en cuenta todos los casos diferentes.

me encantaría algunas sugerencias para una mejor forma de hacer esto.

Me parece que debería ser capaz de cargar los datos una vez en un estado conocido de algún almacén de datos y luego podría usar una instantánea de ese estado que se carga en la configuración de prueba/inicializar antes de cada método de prueba es ejecutado. Esto satisfaría las prácticas de prueba adecuadas a la vez que proporciona comodidad y me permitiría centrarme en escribir pruebas en lugar de escribir código para crear datos de prueba "a mano".

Answer 1

Puede ser que puedas probar la biblioteca de NBuilder. Proporciona una interfaz muy fluida y es fácil de usar. Puede usarlo para generar instancias únicas de una clase con valores defualt o generar listas con valores predeterminados o anulados. Puede echar un vistazo a this uno.

Answer 2

Sé exactamente lo que quieres decir. Creo que un buen enfoque para resolver este problema es tener un proyecto MockFramework separado que contenga todos los datos simulados, fuera del proyecto de prueba. De esta forma puede generar datos falsos por separado, almacenarlos en la memoria si quiere, o no, y luego hacer referencia al marco simulado del proyecto de prueba. Si utiliza un marco de terceros para hacer esto, mucho mejor, pero aún puede ajustar ese marco de terceros en su propio marco simulado para que pueda obtener todo ese "pegamento" que crea los datos simulados de la manera en que lo necesita. sus pruebas para que las pruebas realmente puedan ser solo lo que necesitan ser.

Answer 3

Usted puede tener la clase Constructor (s) que ayuda a la construcción de las que necesite/en este caso las que usaría en relación con el repositorio. Haga que el constructor use los valores predeterminados adecuados, y en sus pruebas puede sobrescribir lo que necesita. Esto le ayuda a evitar la necesidad de tener todos los casos de "datos" mezclados para todas las pruebas diferentes (lo que presenta problemas, ya que generalmente hay casos que no son compatibles para diferentes pruebas).

** Actualización 1: ** Tome un vistazo a www.markhneedham.com/blog/2009/01/21/c-builder-pattern-still-useful-for-test-data

Answer 4

Si su están utilizando .Net Trate NDBUnit

Rellena su tienda y luego se revierte su base de datos a un estado conocido al tiempo de la prueba, para cada prueba. La serie de proyección de pantalla Autumn of Agile muestra esto con bastante buen detalle.

O puede hacerlo manualmente ... crear un procedimiento almacenado o lo que sea para truncar sus tablas y copiar los datos en su método de desmontaje.

Answer 5

Gracias por todas las sugerencias, creo que la solución requiere un poco de todo. No quiero que estas pruebas terminen siendo pruebas de regresión, pero sin algún tipo de almacén de datos existente, todo se reduce a la creación de los datos mediante la construcción "manual" de los objetos.

Lo que realmente sería bueno sería un marco que me permitiera usar mi DAL existente para guiar los datos para codificar para mí u obtener los datos en la memoria y acceder a ellos como una base de datos de memoria.

Answer 6

Untils.org cubre de esta manera mejor de lo que jamás podría.

Toda su guía es realmente muy buena.

Pero básicamente, si sus unidades requieren "una gran cantidad de datos" puede que no sean las pruebas unitarias más. Recomiendo intentar probar las piezas más pequeñas individualmente.