Me pregunto si su base de datos similar a git podría resolver otro espacio de problemas igualmente importante que no mencionó en su publicación del blog: aplicaciones de base de datos de pruebas de unidades .
La prueba de unidad es excelente, pero cuando tienes una aplicación de base de datos, la compensación de costo-beneficio comienza a cambiar.
Aquí es cómo nosotros (y creo que la mayoría de la gente) lo hacemos actualmente: creamos y rellene una base de datos con "datos de prueba" en el método de configuración de la prueba de la unidad (desde un archivo json o un archivo XL, por ejemplo). Luego, incorporamos los datos de prueba json / XL en git como parte de las pruebas unitarias. Pero es un dolor mantenerlo, y no será tan útil como probar contra datos reales . Y a medida que los "datos de prueba" se hacen más grandes, también es muy lento. Importar un archivo de datos de 100MB en mysql es realmente lento.
Uno podría escribir sus pruebas de unidad contra un DB de producción, pero eso tiene todo tipo de problemas: cada vez que el DB cambia, sus pruebas se rompen. O lo que es peor, si lo que está probando muta el DB, podría romper el DB de producción.
Ahora, la unidad de reimaginar de prueba de DB, con DB similar a git:
- Cada estación de trabajo de desarrollador (y máquina de prueba / CI) tiene una copia completa de la base de datos de producción (incluidas todas las versiones) en su estación de trabajo.
- Acceder a cualquier versión particular de la base de datos es solo una cuestión de referencia a un sha.
Esto haría que el problema de las pruebas de unidad de bases de datos sea trivial. ¿Derecha? ¿O es mi pensamiento malo? Aparte de todo el otro valor que aporta su solución, si todo lo que hizo fue resolver el problema de probar las aplicaciones de DB, podría ganar un premio noble por solo que.
No comments:
Post a Comment