¿Cuáles son las mejores prácticas con respecto a las pruebas unitarias de una biblioteca / marco?
Estoy luchando para escribir un conjunto de pruebas unitarias para una biblioteca / marco que estoy diseñando. Para el contexto, por favor, piense en mi biblioteca como una capa de objeto sobre un conjunto jerárquico de objetos relacionados.
PreguntaBásicamente, estoy tratando de adherirme a los principios y mejores prácticas con respecto a las pruebas unitarias como se ve enalgunas publicaciones aquí, pero parecen estar en conflicto con respecto a probar específicamente una biblioteca o un marco.
Por ejemplo, una prueba básica se refiere a "crear un artefacto". Y otro con "removiendo un artefacto". Pero, dado que se supone que una prueba de unidad es independiente y restaura el estado del mundo después de su finalización, ambas pruebas parecen estar relacionadas de alguna manera: al probar la creación de artefactos, debemos limpiar el estado al final de la prueba. quitandolo Esto significa que la eliminación de artefactos se prueba implícitamente. Y el mismo razonamiento se aplica a las pruebas de eliminación de artefactos: para configurar el mundo de modo que la eliminación de artefactos sea comprobable, primero debemos crear un nuevo artefacto.
La situación se agrava cuando necesitamos probar de forma unificada la creación y eliminación de los sub-artefactos relacionados, para lo cual necesitaremos configurar el mundo en consecuencia.
A lo que me inclino es realizar un conjunto de pruebas de unidad relacionadas en secuencia, de modo que cada prueba de unidad sea discreta (es decir, solo prueba una cosa y solo una cosa), pero depende de pruebas previas en la secuencia para configurar progresivamente el mundo. Entonces, mi secuencia podría verse así:
[crear artefacto] -> [crear artefacto secundario] -> [eliminar artefacto secundario] -> [eliminar artefacto]
Con este principio, toda la biblioteca / marco se prueba por unidades, y el estado del mundo se restaura al final de toda la ejecución del conjunto de pruebas. Sin embargo, esto significa que cualquier falla en medio de la suite de prueba "rompe el mundo".
¿Cuáles son algunas de las mejores prácticas y pautas que pueden ser útiles para conciliar esas necesidades conflictivas?
Referencias¿Qué hace una buena prueba unitaria?
¿Es una mala forma tener una prueba de unidad llamando a otras pruebas de unidad?