Ahora hablemos de afirmaciones.
Las afirmaciones son una de las cosas que se dan por sentadas, por lo que todo aquí parecería ser especialista. Alguien usa el Java o Junit incorporado, alguien usa bibliotecas avanzadas, alguien construye el suyo.
Pero tratemos de abordar esto más en serio. ¿Cómo, de hecho, no?
Primero, las aserciones duplican la especificación. Si se especifica la especificación shouldReturnValidOrder, esto debería verificarse y no afirmarNotNull.
En segundo lugar, las afirmaciones deberían ser fáciles de leer. Es decir, al instante, en comparación con la especificación.
Si hay demasiadas afirmaciones (para mi gusto extremo, hay muchas más de una, pero ponemos un límite de al menos cinco a siete), entonces la prueba deja de ser comprensible. Para bien, cada prueba debe tener una sola razón para caer.
Los activos pueden dirigirse a: un campo primitivo, objeto, colección, rara vez una función o thunk.
Cuanto más complejo sea el objeto, más complejas y diversas serán las afirmaciones, y más difícil será leer y encontrar errores.
Las declaraciones positivas se leen mejor que las negativas dobles.
Los métodos estándar se leen mejor que los ayudantes personalizados. (Quién sabe quién y dónde probó la biblioteca de ayudantes). Y las afirmaciones deben estar en el cuerpo del método de prueba, y no en algún lugar en la parte posterior de los asistentes de prueba (el sonar jura con razón sobre la falta de afirmaciones).
Los activos sobre campos son más comprensibles que las afirmaciones sobre objetos, y especialmente sobre colecciones.
En el caso de los campos anidados, tiene sentido realizar una prueba completa.
No
assertNotNull(order.getCustomer().getName)
pero
assertNotNull(order) assertNotNull(order.getCustomer()) assertNotNull(order.getCustomer().getName())
Los asistentes no solo verifican estúpidamente lo que devuelve el método, sino que lo influyen. Y si podemos cambiarlo, entonces necesitamos cambiarlo.
Es relativamente difícil hacer afirmaciones sobre colecciones. ¿Contienen ceros, están ordenados, exactamente cómo están ordenados, cómo se verifica la igualdad de los elementos, etc. - todo esto hace que las colecciones sean objetos difíciles para las afirmaciones, especialmente cuando hay una lógica en el método relacionado con los elementos de las colecciones.
Por lo tanto, un método como:
List<Order> getOrderList(List<OrderDao> orderDaoList){ return orderDaoList.stream().map(orderDao=>order.name(orderDao.getName).build()).collect(Collectors.toList()) }
es fácil dividir en dos, un transformador orderDao => order y probarlo por separado, y el segundo probará el mapeo de colecciones en el mapeador abstracto, y podemos probarlo en el stub.
List<Order> getOrderList(List<OrderDao> orderDaoList, OrderDaoToOrderMapper mapper){ return orderDaoList.stream().map(mapper::map).collect(Collectors.toList()) }
Por otro lado, las colecciones se prestan bien a la tipificación y expansión, es decir podemos hacer relativamente fácilmente una colección de su propio tipo con todas las propiedades probadas, co y contravarianza, etc. Por lo tanto, en lugar de una Lista genérica, podríamos hacer nuestra propia OrderList, OrderSet o OrderSortedSet, y cuanto más específico, mejor. Y las pruebas serán más fáciles.
No es mucho más difícil hacer declaraciones sobre funciones que sobre objetos, y están bien escritas en algunos idiomas, por lo que probablemente pueda recomendar una mejor escritura, es decir. en lugar de Func <Order, Order> devolver algún OrderComparator.