search

autoweirdfm / autoweirdfm.github.io

Die alter (a.k.a. legacy) @Autoweird.fm homepage - Kommentare bitte nur noch über die neue Website!
https://autoweirdfm.github.io
5 stars 2 forks source link

Folge 38: Erzähl mir, wie du testest #42

Open holgergp opened 6 years ago

joshiste commented 6 years ago

IIRC verspricht @britter zwischendurch über die Nutzung von Templates und Builders zu reden tut's aber nicht... Würde mich noch interessieren...

holgergp commented 6 years ago

Ist mir auch aufgefallen. Ist untergegangen. Sorry! In den Shownotes gibt es ein paar erklärende Links.

britter commented 6 years ago

Wir können das als Einschub noch mal in der nächsten Folge etwas ausbreiten.

joshiste commented 6 years ago

Habe gerade reingeschaut, ist ja eigentlich keine Überraschung... aber es gibt ja Leute die behaupten eine shared test fixture sei ein anti pattern...

britter commented 6 years ago

Oh, das wusste ich noch nicht. Hast du da Quellen/Bücher zu? Würde mich echt interessieren. Bisher sind wir mit dem Ansatz gut gefahren.

joshiste commented 6 years ago

Ich glaube das war in dem Talk https://www.youtube.com/watch?v=fr1E9aVnBxw

greelgorke commented 6 years ago

in Benes projekt testen wir auch Interaktionen, auch mit Enzyme (.simulate API) und dann wird geprüft, ob entweder der State der Komponente geändert wurde, oder, was meist der Fall is, ob die richtige Action mit richtigen Parametern gefeuert wurde. Der ActionCreator ist dann ein Mock.

Zum Thema Compiler vs Testing: Genau, der Compiler ist quasi eine Precondition. In JS testen wir aber relativ selten ob das die richtige Instanz ist, aka vom passendem Typ. Viel mehr schauen ob es eine Ente ist. Was letzlich auch ein Precondition-Check ist. Dann kann ich auch Design by Contract machen, was meinen Testaufwand reduzieren kann.

Ich glaube das, was ich über die paar Jahre der Auseinandersetzung zwischen Dynamic und Static typing, gelernt habe, ist dass beide Lager eine leicht unterschiedliche Attitüde gegenüber dem Nutzer des Codes pflegen. Static Typing sagt: Wenn du meine Bedingungen komplett erfühlst (Kompiler), garantiere ich, ich tue, was du erwartest. Dynamic Typing sagt: Du kannst tun was du willst, wenn du meine Annahmen triffst, erfülle ich dir deine Erwartung, wenn nicht.... nun es ist dein Code ¯_(ツ)_/¯

Die menge an Testing ist vergleichbar. In JS ersetzt man den Compiler durch Lint und Precondition Checks.

my 2 cents

greelgorke commented 6 years ago

Man muss zum Enten-check aber noch sagen, das formale PRekondition checks eher selten passieren, da wird sich eher auf die Runtime verlassen, was meist gut geht (Und mit Reference- und TypeErrors quitiert wird). Gute API Schreiber machen aber die Formalen checks.

LukaJCB commented 6 years ago

Um meinen Senf auch nochmal dazu zu geben, testing mit nem guten Compiler & Refined ist für mich deutlich deutlich einfacher, da man nun genaue Spezifikationen angeben kann und seine Funktionen mit Properties a la QuickCheck (ScalaCheck etc.) testen kann und somit direkt alle Edge Cases mit testet, das kriegt man mMn manuell niemals so gut hin :)

Auf jeden Fall eine sehr coole Folge, weiter so :)

britter commented 6 years ago

Bei Circe benutzen sie ja Laws um die Eigenschaften der Encoder und Decoder zu testen. Das finde ich auch einen interessanten Ansatz (den ich aber noch nicht vollständig durchdrungen habe)