Lassen Sie uns nun über Behauptungen sprechen.
Behauptungen sind eine Selbstverständlichkeit, daher scheint hier alles Spezialisten zu sein. Jemand verwendet das integrierte Java oder Junit, jemand verwendet erweiterte Bibliotheken, jemand erstellt seine eigenen.
Aber versuchen wir es ernsthafter. Wie eigentlich?
Erstens duplizieren Behauptungen die Spezifikation. Wenn die Spezifikation shouldReturnValidOrder angegeben ist, sollte dies überprüft werden und nicht assertNotNull.
Zweitens sollten Behauptungen leicht zu lesen sein. Das heißt, sofort mit der Spezifikation zu vergleichen.
Wenn es zu viele Behauptungen gibt (in meinem extremen Geschmack gibt es viel mehr als eine, aber wir werden eine Grenze von mindestens fünf bis sieben festlegen), dann ist der Test nicht mehr verständlich. Jeder Test sollte nur einen Grund zum Fallen haben.
Assets können gerichtet werden auf: ein primitives Feld, ein Objekt, eine Sammlung, selten eine Funktion oder ein Thunk.
Je komplexer das Objekt ist, desto komplexer und vielfältiger werden die Aussagen und desto schwieriger wird es, sie zu lesen und Fehler zu finden.
Positive Aussagen lesen sich besser als doppelt negative.
Standardmethoden werden besser gelesen als benutzerdefinierte Helfer. (Wer weiß wer und wo hat die Helferbibliothek getestet). Und die Aussagen sollten sich im Kern der Testmethode befinden und nicht irgendwo im Hintergrund der Testhelfer (das Sonar schwört zu Recht auf das Fehlen von Aussagen).
Assets zu Feldern sind verständlicher als Aussagen zu Objekten und insbesondere zu Sammlungen.
Bei verschachtelten Feldern ist es sinnvoll, vollständig zu testen.
Nicht
assertNotNull(order.getCustomer().getName)
aber
assertNotNull(order) assertNotNull(order.getCustomer()) assertNotNull(order.getCustomer().getName())
Asser prüfen nicht nur dumm, was von der Methode zurückgegeben wird, sondern beeinflussen sie. Und wenn wir es ändern können, müssen wir es ändern.
Aussagen über Sammlungen sind relativ schwer zu treffen. Enthalten sie Nullen, sind sie sortiert, genau wie werden sie sortiert, wie werden Elemente auf Gleichheit geprüft usw. - All dies macht Sammlungen zu schwierigen Objekten für Behauptungen, insbesondere wenn die Methode Logik in Bezug auf die Elemente von Sammlungen aufweist.
Daher eine Methode wie:
List<Order> getOrderList(List<OrderDao> orderDaoList){ return orderDaoList.stream().map(orderDao=>order.name(orderDao.getName).build()).collect(Collectors.toList()) }
Es ist einfach in zwei Teile aufzuteilen, einen Transformator orderDao => separat bestellen und testen, und der zweite testet die Zuordnung von Sammlungen auf dem abstrakten Mapper, und wir können sie auf dem Stub testen.
List<Order> getOrderList(List<OrderDao> orderDaoList, OrderDaoToOrderMapper mapper){ return orderDaoList.stream().map(mapper::map).collect(Collectors.toList()) }
Andererseits eignen sich Sammlungen gut zur Typisierung und Erweiterung, d.h. Wir können relativ leicht eine eigene Sammlung mit allen getesteten Eigenschaften, Co- und Contravariance usw. erstellen. Daher können wir anstelle einer generischen Liste auch eine eigene OrderList oder OrderSet oder OrderSortedSet erstellen. Je spezifischer, desto besser. Und die Tests werden einfacher.
Aussagen über Funktionen zu machen ist nicht viel komplizierter als über Objekte, und sie sind in einigen Sprachen gut geschrieben, so dass Sie wahrscheinlich eine bessere Typisierung empfehlen können, d. H. anstelle von Func <Order, Order> geben Sie einen OrderComparator zurück.