building a product Cover

building a product

Sven Wiegand – orgavision GmbH
Since 02/2023 7 Episoden

006: Automatische Tests im Frontend

Methoden und Herausforderungen automatischer Tests im Frontend

02.05.2023 60 min

Zusammenfassung & Show Notes

Sascha führt uns durch die Teststrategien, die wir in unserem react Frontend nutzen. Der Wechsel von enzyme zu React-Testing-Library (RTL) steht dabei im Vordergrund.

Sascha führt uns durch die Teststrategien, die wir in unserem react-Frontend nutzen. Dabei gehen wir auf folgende Themen ein:
  • Unit-Tests mit Jest
  • Integration-Tests mit Jest und React Testing Library
  • Umstieg von Enzyme zu React Testing Library
  • Vor- und Nachteile von React Testing Library
  • DOM- und Image-Snapshot-Tests mit Storybook und Chromatic
  • Wirtschaftlichkeit automatischer Tests im Frontend

Transkript

Sven
00:00:03
Heute reden wir über automatische Frontend-Tests. Letzte Woche haben wir über – oder was heißt letzte Woche – beim letzten Mal haben wir über die automatischen Tests im Backend geredet. Es ist natürlich naheliegend, dass es jetzt auch noch ums Frontend geht. Und dafür bin ich diesmal wieder mit dem Sascha zusammen.
Sascha
00:00:39
Hallöchen.
Sven
00:00:42
Ja. Frontend-Tests. Die Herausforderung sind natürlich genau die gleichen. Also es geht darum, dass wir irgendwie automatisiert unsere Software testen, um Fehler auch frühzeitig zu finden. Also wir wollen den gleichen Nutzen erreichen. Der Technologie-Stack ist natürlich ein ganz anderer. Deswegen will ich sagen, lass uns noch mal zuerst darauf gucken, was für Testvarianten haben wir überhaupt? Und dann gehen wir hinterher mal bei den einzelnen Sachen ins Detail, wie wir das machen. Was für Tests würdest du denn unterscheiden?
Sascha
00:01:15
Ja, wir haben da recht viele Integrationtests, wenn es auch ganz neue ist mit RTL. Einige wenige Tests haben wir dann auch wieder. Eigentlich recht viele Snapshot-Tests. Bei Snapshot haben wir so Image und Snapshot.
Sven
00:01:35
Alles klar, dann gucken wir mal die verschiedenen Sachen an. Aber vorher noch mal Framework. Du hast eben schon von RTL gesprochen. Und damit meinst du wahrscheinlich nicht den Fernsehsender.
Sascha
00:01:46
Also kommt mir auch immer in den Sinn. Ehrlich gesagt, wenn ich RTL sage, vielleicht muss ich RTL sagen und dann verändert sich die Assoziation hier.
Sven
00:01:53
Sehr subtil.
Sascha
00:01:57
Genau. Vor nicht allzu langer Zeit hatten wir noch enzyme.
Sven
00:02:03
Im Core-Produkt Nutzen wir das auch noch zu großen oder für fast alle Tests?
Sascha
00:02:08
Genau da haben wir jetzt auch angefangen, teilweise schon auf RTL zu wechseln. Aber ja, und in unserem neuen Projekt wollten wir dann direkt auf RTL mit RTL starten, weil es ja im Grunde nicht mehr weiterentwickelt wird. Und ja.
Sven
00:02:29
Eine krasse Sache. Also irgendwie so gefühlt war das der STANDARD, den man bei React Projekten halt gemacht hat, dass man gesagt hat, ein Projekt setz ich halt auf mit jest und enzyme. Das war jahrelang der STANDARD gewesen. Und deswegen bin ich ja schon erstaunt, dass die Entwicklung von dem System irgendwie komplett eingestellt wurde und dass ich da auch irgendwie, obwohl es so verbreitet war, keine Community drum gebildet hat, die das irgendwie weiterentwickelt, wie es ja doch häufig bei stark eingesetzten Open Source Frameworks doch der Fall ist. Aber hier scheint es doch alles an Airbnb gehangen zu haben. Und als die das dann nicht mehr genutzt haben oder keine Lust mehr hatten oder was auch immer da der Auslöser war, hat es dann glaube ich noch mal für zwei React Versionen irgendwelche Adapter von irgendwelchen Independent Developers gegeben. Aber jetzt für die aktuellste React Version 18 hilf mir kurz.
Sascha
00:03:21
Also 18 haben wir gerade am Laufen.
Sven
00:03:22
Ja, genau. Da gibt es tatsächlich gar nichts mehr. Da ist einfach für enzyme nichts mehr verfügbar und damit ist es nicht nutzbar.
Sascha
00:03:30
Ja, also ich weiß gar nicht, ob nicht mittlerweile doch irgendwer irgendetwas gemacht hat, aber als wir uns entschieden hatten, war es auf jeden Fall so und es gibt ja noch.
Sven
00:03:39
Ich hatte neulich noch mal extra. Ich hatte neulich nochmal extra geguckt und scheint immer noch nicht verfügbar zu sein.
Sascha
00:03:45
Ja, es gibt ja noch den React Test Renderer, der glaube ich direkt vom Team kommt und ich glaube auf dem Board auch RTL auf. Ähm, das war auch noch eine Alternative zu einem, die es schon immer gibt und auch immer noch gibt. Vielleicht weiß ich auch nicht genau. Oder beides in einem, der Renderer nimmt. Oder ich glaube beide nutzen ihn. Irgendwas war da, aber RTL bietet dann halt natürlich noch Utility Funktionen dazu, ohne das man diesen ganzen Kram nicht machen muss. Das war ja auch so, eigentlich glaube ich mit der Idee dahinter das so zu entwickeln, dass man viel einfacher als bei seinem Text schreiben kann und auch mehr Predictive Tests drin hat.
Sven
00:04:32
Ja, lassen wir mal kurz auf die grundlegenden Unterschiede eingehen. Also RTL steht für REACT-TESTING Library. Haben wir glaub ich noch gar nicht gesagt. Und das scheint so der neue STANDARD zu sein. Ist aber so habe ich dich verstanden, nicht direkt vom React Team, sondern ist auch wieder irgendeine Independentgeschichte, weißt du das? Okay, okay. Und das hat sich jetzt aber als STANDARD etabliert in den letzten Jahren. Also jetzt ist es selbstverständlich, dass man Artikel nutzt oder wie würdest du das einschätzen? Genau der grundlegende unterschiedliche Ansatz ist. Ja, bei einem habe ich richtige, Unittests geschrieben, das heißt, da habe ich gelesen, dass da ab. Also was, wie ist man da üblicherweise vorgegangen, um mit seinem eine Komponente zu testen? Wo ist denn? Ja. Wo ist da der grundlegende Unterschied? Also am Ende machen sie ja beide irgendwie das Gleiche. Sie rendern einen Dom, auf dem ich dann irgendwelche Testfahrer und sage ich erwarte, dass hier das und das Attribut ist. Insofern klingt es ja erst mal so, als wenn Sie beide das Gleiche tun.
Sascha
00:07:51
Kann man also im Grunde tun. Sieht es ja auch mal an viel Feature Überlappungen. Aber ich glaub der Hauptunterschied ist einfach, dass im Artikel wird halt ein sogenannter in en sprechenden Fullmount gemacht, und das heißt einfach alles wird gerendert was so rein gibt und in unserem war das auch möglich. Aber man hat dann sich oft für den Shell Render entschieden statt einem Vollmount. Ähm um einfach so einen Test performant zu halten. Ähm, ja, so eine.
Sven
00:08:27
Brunnen haben die Unterschieden der Ränder, der Mauern und der Schallränder. Da wurde nur die erste Komponentenebene gerendert, oder.
Sascha
00:08:35
Genau. Nur das erste Level und zwei.
Sven
00:08:38
Also keine Zeit Components von der Komponente, die ich gerade teste.
Sascha
00:08:43
Richtig. Die könntest du auch rendern, wenn du das wolltest. Du kannst dann Dive zum Beispiel machen und dann ging es eine Ebene tiefer, was auch so seine ors hatte. Keine Frage, da gab es auch Probleme, aber zumindest hatte man da schon dann auch die Kontrolle. Und mit Artikel geht es auch. Aber dann musst du halt die Components macken, also mit JOSM zum Beispiel. Und dann, je nach Komponente ist das halt nützlich oder nicht. Aber es ist eigentlich nicht der Ansatz, den man bei RTL verfolgt. Man will ja eigentlich die Component als Ganzes so testen, wie der Nutzer sie wahrnimmt und eben nicht so einzeln. Ist genau.
Sven
00:09:23
Viel weggenommen. Noch mal ganz kurz bei ihm waren es denn auch unterschiedliche Doom Technologien, falls man das so sagen kann. Bei dem Shadowrun Render und bei dem Fullmount.
Sascha
00:09:37
Soweit ich weiß, nutzen beide just um.
Sven
00:09:39
Okay. Also war wirklich nur wirklich nur die Unterscheidung, dass die komplette Hierarchie durch Rendern oder halt gerade nicht?
Sascha
00:09:45
Ja. So war gestern. Es ist glaube ich falsch. Also jetzt und JS Dom oder so heißt es. Glaube jetzt Omas Pakete.
Sven
00:09:52
Okay. Okay, gut. Und das heißt ja eigentlich, der große Unterschied ist der wenn ich dich jetzt richtig verstanden habe, dass du bei React-testing, hast du halt nur diesen Fullmount und nicht mehr den Shadow Renderer. Wende Shadow wirklich nur eine Komponenten Ebene testen willst, dann musst du halt Max für die Schalt Components reinschieben und dann könntest du theoretisch auf die gleiche Art testen, nur weiß, ob dann die Performance auch gleich wäre. Naja, wenn sie gleiche Domtechnologie nutzen wahrscheinlich schon.
Sascha
00:10:17
I. Na ja, also. Also wahrscheinlich gibt es intern da noch viel mehr Details, die sich unterscheiden. Und ich würde auch nicht sagen, dass man dann gleich testen kann, weil die ganzen so oder so sind, einfach auch anders in so oft so gearbeitet, dass so eine Komponente selektiert fast über einen Konstruktor. Also zumindest haben wir es so gemacht. Ja, dann hast du die Component, die da oder die Instanz der Component, die da gerendert wurde und dann holst du die Props davon und kann zum Beispiel nen OnClick auf einen Button. Ja, damit du Tests okay, wenn der Button geklickt wurde. Und soweit kann man ja durchaus vertrauen, dass onClick ausgeführt wird, wenn ein Klick Event gefeuert wird. Deswegen finde ich es auch, dass einfach nur Props onClick zu koppeln. Ähm, genau so als Beispiel. Und in der Regel hast du gar nicht diese Möglichkeit, sondern du musst dann über mit dem Dom quasi arbeiten. Also du sagst dann eher gib mir den Button, der das Label Klickmich hat und dann für ein Klick auf den Button aus.
Sven
00:11:24
Und als ich nicht selber die Funktion auf, sondern es ist wirklich ein echter Klick. Und dann will ich zum Beispiel auch mitkriegen, wenn die OnClick Funktion gar nicht am Element hinterlegt worden wäre und man ganz banales Beispiel zu nehmen. Wenn ich einen Klick gar nicht registriert worden wäre, das würde dann zum Beispiel, wäre bei dem in seinem Test vielleicht nicht aufgefallen. Hier würde es auffallen, weil dann der Klick nicht durchkommen würde. Ja okay, klar, hat ja auch direktes OnClick Event aufgerufen. Vor allen Dingen Textrendering. Aber das ist ein anderes Thema. Und sag mal noch mal, bevor wir noch mal auf React-testing lyrI kommen Was ist eigentlich die Abgrenzung zwischen Jazz und, React-testing Library? Also welche Aufgaben übernimmt Jazz und was macht React-testing Library? Und diese ganzen Serbiens und Schutz Syntax, wo ich schreibe das und das Element sollte jetzt den und den das und das Label haben, was das kommt da aus jetzt und was aus React-testing Library. Macht es einfach leichter, knackiger zu schreiben und leichter zu lesen. Ja. Okay. Gut. Also dann zurück zu React-testing Lei. Genau. Das heißt, die Idee bei denen ist. Und das propagieren Sie ja, glaub ich auch, ganz klar. Also sagen wir wollen realistischere Testszenarien, in dem man halt wirklich so einen Full Render Test macht und halt weggeht von den einzelnen Units, weil man dann am Ende eigentlich nur ganz viel moching und ganz viel Interna testet. Die einen, die eigentlich für die Funktionalität oder für das, was der Endanwender sieht, überhaupt nicht relevant sind und dadurch wahrscheinlich auch sehr häufig angepasst werden, müssen die Tests dann. Ja, und auf welcher Ebene testen wir da? Also wir testen dann trotzdem noch jede Komponente, die wir selber entwickeln. Oder testen wir auch teilweise ganze Dialoge dann mit RTL, RTL oder wie kann ich mir das vorstellen? Okay. Und dann eben ganz klassisch in das Ich sowohl. Na, was heißt ganz klassisch, dass ich sowohl meine einzelnen Komponenten teste, wie eben gesagt, aber dann halt auch durchaus, halt einen Verbund aus Komponenten, um quasi zum Beispiel einen Dialog oder so was halt dessen Funktionalität durchzuchecken in Bezug auf was weiß ich Validierung von den Feldern, die da drin sind oder so was.
Sascha
00:22:20
Ja, und da sind wir dann auch schon wieder bei Tools wie Cypress. Ähm, im Grunde ist das hat hat so was wie Cypress ähnliche Issues. Ähm, also ich meine jetzt nicht Cypress speziell, sondern einfach diese Art von Akzeptanztests, die dann gegen irgendeine Website laufen und da Sachen überprüfen. Da gibt es ja auch diese ganzen Probleme irgendwo. Ein ganz interessant. Ja, das Environment, ganz klar. Genau. Der eine läuft auch im Browser, also Cypress in dem Fall und ähm, RTL halt nicht. Was auch den Vorteil hat, man kann doch ein bisschen kleinteiliger auch die Umgebung, vorkonfigurieren bereitstellen. Und bei Cypress willst du ja in der Regel gegen das laufen, was jetzt da ist, was bei RTL ja auch irgendwo der Ansatz ist. Aber manchmal musst du trotzdem irgendwas bereitstellen und. Auf jeden Fall eher. Ja.

Feedback

Wir freuen uns über Dein Feedback – sowohl zu unseren technischen Erlebnissen und Entscheidungen als auch zu unserem Podcast. Gibt es vielleicht ein Thema, dass Du gerne behandelt haben möchtest? Dann kontaktiere uns hier gerne.

Mit einem Klick auf "Nachricht absenden" erklärst Du Dich damit einverstanden, dass wir Deine Daten zum Zwecke der Beantwortung Deiner Anfrage verarbeiten dürfen. Die Verarbeitung und der Versand Deiner Anfrage an uns erfolgt über den Server unseres Podcast-Hosters LetsCast.fm. Eine Weitergabe an Dritte findet nicht statt. Hier kannst Du die Datenschutzerklärung & Widerrufshinweise einsehen.

★★★★★

Gefällt Dir die Show?
Bewerte sie jetzt auf Apple Podcasts

2024 - Sven Wiegand – orgavision GmbH

Hosted by LetsCast.fm
Deinen eigenen Podcast erstellen