This repository has been archived by the owner. It is now read-only.

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

Open
holgergp opened this Issue Feb 25, 2018 · 10 comments

Comments

Projects
None yet
5 participants
@holgergp
Contributor

holgergp commented Feb 25, 2018

No description provided.

@joshiste

This comment has been minimized.

joshiste commented Feb 26, 2018

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

@holgergp

This comment has been minimized.

Contributor

holgergp commented Feb 26, 2018

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

@britter

This comment has been minimized.

Member

britter commented Feb 26, 2018

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

@joshiste

This comment has been minimized.

joshiste commented Feb 26, 2018

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

@britter

This comment has been minimized.

Member

britter commented Feb 27, 2018

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

This comment has been minimized.

joshiste commented Feb 27, 2018

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

@greelgorke

This comment has been minimized.

greelgorke commented Feb 28, 2018

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

This comment has been minimized.

greelgorke commented Feb 28, 2018

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

This comment has been minimized.

LukaJCB commented Mar 6, 2018

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

This comment has been minimized.

Member

britter commented Mar 6, 2018

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)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.