En general, agrega todos los pasos de requisitos previos a la configuración y todos los pasos de limpieza a tearDown.
Puede leer más con ejemplos aquí .
Cuando se define un método setUp (), el ejecutor de la prueba ejecutará ese método antes de cada prueba. Asimismo, si se define un método tearDown (), el ejecutor de la prueba invocará ese método después de cada prueba.
Por ejemplo, tiene una prueba que requiere que existan elementos, o cierto estado, por lo que coloca estas acciones (crear instancias de objetos, inicializar db, preparar reglas, etc.) en la configuración.
Además, como sabe, cada prueba debe detenerse en el lugar donde se inició; esto significa que tenemos que restaurar el estado de la aplicación a su estado inicial, por ejemplo, cerrar archivos, conexiones, eliminar elementos recién creados, llamar a transacciones de devolución de llamada, etc. los pasos deben incluirse en el tearDown.
Entonces, la idea es que la prueba en sí debe contener solo acciones que se realizarán en el objeto de prueba para obtener el resultado, mientras que setup y tearDown son los métodos que le ayudarán a dejar su código de prueba limpio y flexible.
Puede crear un setUp y tearDown para un montón de pruebas y definirlas en una clase principal, por lo que sería fácil para usted respaldar dichas pruebas y actualizar las preparaciones y limpiezas comunes.
Si está buscando un ejemplo sencillo, utilice el siguiente enlace con un ejemplo
Suponga que tiene una suite con 10 pruebas. 8 de las pruebas comparten el mismo código de instalación / desmontaje. Los otros 2 no lo hacen.
La configuración y el desmontaje le brindan una buena manera de refactorizar esas 8 pruebas. Ahora, ¿qué haces con las otras 2 pruebas? Los movería a otro caso de prueba / suite. Por lo tanto, el uso de configuración y desmontaje también ayuda a brindar una forma natural de dividir las pruebas en casos / conjuntos
fuente