En el
煤ltimo texto sobre afirmaciones , faltaba algo importante y no se acord贸.
驴Cu谩l es la diferencia entre dado y cu谩ndo y c贸mo se relaciona esto con las afirmaciones?
La idea subyacente es simple: queremos limitar el n煤mero de afirmaciones.
Considere un peque帽o ejemplo.
Pasemos alg煤n objeto v谩lido al m茅todo, llame al servicio adicional y enriquezca sus propiedades.
No tengo que escribir c贸digo antes de la prueba, por lo que asumiremos que esto es solo para transmitir el panorama general.
public User enrichUser(User validUser){ user.setDetails(enrichmentService.getUserDetails(validUser.getId())); return user; }
No nos interesan las variaciones v谩lidas de usuario. No es nulo, siempre tiene una identificaci贸n, luego es v谩lido. Esta es una condici贸n previa, es decir dado.
De hecho, debemos considerar dos condiciones: enriquecimiento, falla del servicio y 茅xito. Esta es una condici贸n, es decir cuando
驴C贸mo distinguir uno del otro?
Dado no requiere verificaci贸n de otros casos, cuando - requiere. Es decir whenValidUser requiere whenInvalidUser, y givenValidUser no.
Y enrichmentservice == null? Si inyectamos una dependencia, entonces podemos considerar esta parte de la configuraci贸n y no pensar en ella en las pruebas. Absolutamente Hay condiciones previas que no tiene sentido enumerar.
Si el m茅todo acepta solo usuarios, aumenta el n煤mero de scripts que se verifican. Dado se convierte en cu谩ndo.
Otra pregunta, pero, estrictamente hablando, por accidente o intencionalmente, 驴un m茅todo puede arruinarnos un usuario? 驴No deber铆amos echarle un vistazo?
Si respondemos que s铆, debemos hacerlo, tendremos que admitir que esto puede ser una gran carga. Un usuario puede tener cincuenta propiedades, y verificarlas en cada m茅todo puede ser costoso. Hay comprobaciones masivas utilizando bibliotecas, pero al hacer esto perdemos la funci贸n importante de la prueba: prescribir la funcionalidad deseada y no recoger la suciedad detr谩s de la curva de implementaci贸n.
Esto se puede comparar con la seguridad del aeropuerto: alguien revisa el boleto, el equipaje de alguien, los bolsillos de alguien y los cheques no se duplican en cada paso. Es decir Los activos conf铆an en lo que har谩 la implementaci贸n y verifican solo lo que prescriben.
Por lo tanto, una condici贸n previa construida correctamente reduce el n煤mero de scripts y aserciones. Hacemos afirmaciones solo bajo condici贸n.
Desafortunadamente, los marcos como Cucumber no hacen mucha diferencia, porque las condiciones previas en s铆 mismas no los verifican como Dado, que Cuando es el mismo, t茅rmino puramente descriptivo.
En casos m谩s complejos, es dif铆cil distinguir uno del otro, que en s铆 mismo huele. Por ejemplo, muchas pruebas seguidas verifican lo mismo, o algunas de las condiciones en las pruebas se olvidan o se ignoran como inapropiadas.
Esta es una buena raz贸n para reestructurar las especificaciones y el redise帽o.