现在让我们谈谈断言。
断言是理所当然的事情之一，因此这里的所有内容似乎都是专家。 有人使用内置的Java或Junit，有人使用高级库，有人建立自己的库。
但是，让我们尝试更认真地解决这个问题。 实际上如何，对吗？
首先，断言重复了规范。 如果指定了规范shouldReturnValidOrder，则应对此进行检查，而不是assertNotNull。
其次，断言应该易于阅读。 即，立即与规格进行比较。
如果断言太多（就我的极端品味而言，有不止一个断言，但我们将极限值限制为至少五到七个），则测试将变得无法理解。 好的，每次测试只有一个下降的原因。
资产可以定向到：基本字段，对象，集合，很少是函数或实体。
对象越复杂，声明将越复杂和多样化，并且读取和发现错误也将越困难。
肯定的陈述要比双重否定的陈述更好。
标准方法比自定义帮助器更好地阅读。 （谁知道谁在哪里测试了帮助程序库）。 断言应该在测试方法的主体中，而不应该在测试助手的后面（声纳正确地发誓说缺少断言）。
关于字段的资产比关于对象（尤其是集合）的断言更容易理解。
对于嵌套字段，完全测试是有意义的。
不可以
assertNotNull(order.getCustomer().getName)
但是
assertNotNull(order) assertNotNull(order.getCustomer()) assertNotNull(order.getCustomer().getName())
断言器不仅愚蠢地检查方法返回的内容，而且会影响它。 如果我们可以更改它，那么我们需要更改它。
对集合进行断言相对困难。 它们是否包含零，是否进行了排序，究竟如何进行了排序，如何检查元素是否相等，等等。 -所有这些使集合很难成为断言的对象，尤其是当方法中有与集合元素有关的逻辑时。
因此，方法如下：
List<Order> getOrderList(List<OrderDao> orderDaoList){ return orderDaoList.stream().map(orderDao=>order.name(orderDao.getName).build()).collect(Collectors.toList()) }
可以很容易地分为两个，一个转换器orderDao => order并分别对其进行测试，第二个转换器将在抽象映射器上测试集合的映射，我们可以在存根上对其进行测试。
List<Order> getOrderList(List<OrderDao> orderDaoList, OrderDaoToOrderMapper mapper){ return orderDaoList.stream().map(mapper::map).collect(Collectors.toList()) }
另一方面，馆藏非常适合于类型化和扩展，即 我们可以相对容易地收集所有经过测试的属性，协方差和协方差等的自身类型集合。 因此，我们可以使用自己的OrderList或OrderSet或OrderSortedSet代替通用List，并且越具体越好。 并且测试将变得更加容易。
关于函数的陈述比对对象的陈述要困难得多，而且它们在某些语言中的类型很好，因此您可能会建议使用更好的类型，即 代替Func <Order，Order>返回一些OrderComparator。