Pruebas unitarias Aplicaciones Dababase

Question

Estoy tratando de entrar en el ámbito TDD, y estoy teniendo dificultades para probar algunos modelos de usuario que tengo. Estoy tratando de probar la validación de mis modelos, y los requisitos de negocio son los siguientes:

1. > = 6 caracteres nombre de usuario requiere
2. > = 5 contraseña de carácter, con al menos 1 letra y número
3. formato de correo electrónico válida requiere
4. ... bla, bla, bla
5. nombre de usuario y correo electrónico no puede existir ya en la base de datos

Todos los requisitos son fácilmente comprobable, excepto 5, que requiere que la base de datos esté en un estado conocido. Sé que con PHPUnit puedo configurar mi base de datos para que esté en un estado conocido usando archivos XML, pero ¿hay una mejor manera?

Lo que quiero es que mi base de datos regrese al estado en que se encontraba antes de ejecutar las pruebas (es decir, durante el desarrollo). Supongo que podría usar las transacciones de MySQL para deshacer los cambios, o supongo que también podría usar dos bases de datos separadas, una para el desarrollo y otra para las pruebas.

También leo en alguna parte para no utilizar las conexiones de DB reales en las pruebas unitarias, y en su lugar usar datos simulados. No estoy seguro de cómo funciona eso.

¿Puede alguien explicarme las diferentes opciones que tengo y cuáles son las mejores?

Gracias

Editar:

Creo que voy a ir con el enfoque de Ruby on Rails y acaba de crear bases de datos separadas 3, la producción, desarrollo y pruebas. A menos que alguien tenga una fuerte objeción.

Answer 1

Algunas personas dicen que no pruebes en una base de datos, otras como yo dicen que es la única forma en que sabrás si tu código DAO es bueno.

Lo que necesita es dos bases de datos. Uno para probar y otro para desarrollo. La mejor práctica es tener una superclase común para las pruebas de su unidad que configura la base de datos (tal vez dentro de un esquema nuevo) y luego todas las pruebas de su unidad DB se ejecutan en esa base de datos. Puedes limpiarlo después

Para la prueba que mencionaste (el nombre de usuario y el correo electrónico ya no pueden existir en la base de datos), haz algo como esto (código psuedo).

Create user with username that you know doesn't exist (say username-largerandomuuid) 
Insert user. 
Assert user was created 

Insert same user(name) 
Assert error is thrown.