Folge 47: Die Testing Trophy

[joshiste]

iirc gibt es ein Tool für Java, was den Code aus den javadoc ausführt und testet...

Könnte das hier sein, ist aber sehr alt: https://github.com/jakewins/javadoctest/

[woolfred]

Beim Thema private Methoden testen muss ich neuerdings immer an einen Tweet von Mike Hill denken:

[...] "what do i do when i want to test a private" question: don't. make it public on the Impl and test it there. don't mention it in the interface. [...]

Dann muss man sich aber auch ans Design Prinzip Program to an interface, not an implementation halten.

Bin auch vor einiger Zeit über den Beitrag gestolpert und hatte ähnliche Gedanken wie ihr. Danke für die Folge!

[dl1ely]

Vor Elixir hatte es auf jeden Fall schon Python: https://docs.python.org/3/library/doctest.html (Von wem hat es Python? Who knows...)

Und selbstverständlich hat die geilste Programmiersprache ever, also Clojure, das entweder als Konzept „Tests als Metadata an der Funktion“ (https://clojure.org/reference/special_forms#def) oder auch als klassisches „Test in der Dokumentation drin“ (https://github.com/Kobold/clj-doc-test — Ooops, schon 9 Jahre alt...).

;-)

[jwedel]

Shameless self-plug: Zum Thema "Testing" habe ich vor ner Weile auch was geschrieben: Everything That's Not Tested Will Break

Natürlich auch mit reißerischer Überschrift, wie sich das so gehört. Nur weil ihr meintet, es gibt zu wenig Artikel ;) Würde mich auch über Feedback freuen.

[woolfred]

Oder wie wäre es mit dem Testing Honeycomb? Laut den Spotify Leuten werden Integration Tests, im Rahmen einer Microservice-Architektur, "wichtiger":

The biggest complexity in a Microservice is not within the service itself, but in how it interacts with others, and that deserves special attention. https://labs.spotify.com/2018/01/11/testing-of-microservices/

[britter]

Das Thema hatten wir ja in Folge 42: Über Honigwaben und Container schon mal andiskutiert. Auf Twitter wurde auch der Wunsch geäußert, dass wir das noch mal ausführlicher diskutieren...