 Als erst mal einen ganz kurzen Wunsch an euch gibt mir oder ich fände es schön, wenn ihr mir einfach irgendwie ein Zeichen geben könnt, dass ihr da seid. Also winkt mal, steht mal auf, macht einen Ton, hey, schön, dass ihr da seid. Danke. Wir kommen zum Session, zum Vortrag Unit Test React. Ich sage euch ganz kurz, was meine Einladung ist, was ich heute mit euch vorhab, ist so in drei Teile geteilt. Der erste Drittel soll darum gehen, wie komme ich eigentlich auf die Idee, eine Session zum Thema Unit Test React machen zu wollen. Warum bleibe ich immer wieder an dem Thema Testing hängen? Da habe ich mir einfach die Zeit genommen, jetzt in den Vorbereitungen das nochmal für mich zu reflektieren und so ein bisschen auf Meta-Ebene eigentlich zu gucken, was finde ich eigentlich daran spannend oder ja, also was sehe ich da drinnen. Im zweiten Teil können wir ein bisschen zusammenprogrammieren, also es geht ganz konkret darum. Ich habe ein Mini-Test-Projekt dafür, für ein paar Komponenten in React, ein ganz einfachen Unit Test zu schreiben und zwar in der Form, wie ich es für sinnvoll und gut halte. Und im dritten Teil deswegen auch die Klammer um Unit, einfach ein ganz kurzer Ausblick, funktionale End-to-End-Tests, weil ich finde, das spielt immer Hand in Hand und ich weiß jetzt noch nicht genau, wir müssen auch probieren mit euch zu interagieren. Was euer Hintergrund ist, aber so Browserautomatisierung und letztendlich das zu testen, was der User letztendlich kriegt und nicht irgendeine abgeschlossene kleine Unit, finde ich auch immer spannend. Das Ganze stelle ich mir so vor, also die Session, ich gebe dem ganzen Rahmen. Ich finde es spannend, wenn ein Input auch von euch kommt, das ist keine Best Practice jetzt oder irgendwas, sondern einfach ein Einblick in das, womit ich mich sozusagen beschäftige oder was ich in dem Hinblick für wichtig befinde und wie gesagt, da einfach die Einladung zum Austausch und was ich natürlich auch wieder gemerkt habe, wenn man so eine Session vorbereitet, dann darf man sehr viel lernen, also ist auch ein Grund, so was zu machen. Den Spruch hier kennt ihr alle, wenn ich 8 Stunden Zeit hätte, ein Baum zu fällen, würde ich 6 Stunden lang die Axt schleifen. Das ist dieses Thema, warum eigentlich testen? Was sehe ich dahinter, was für Vorteile ergeben sich oder warum kann das wichtig sein? Da gibt es hier diesen Typ, Simon Sinek, ich weiß nicht genau, wie man den ausspricht. Der hat ein Buch geschrieben, genau, der dreht sich bei dem halt alles sozusagen um das Why und da möchte ich ganz kurz auch darüber sprechen, warum ich überhaupt auf die Idee komme, sozusagen JavaScript und über React, zu sprechen auf einem WordCamp. Das hat folgende Hintergrund, das hier ist Mark Antresen oder so. Der hat Mosaik, also einer der ersten Browser mitentwickelt und der hat damals gesagt, in short, Software is eating the world. Ich sage ein bisschen übertrieben, JavaScript is eating the world. Also ich kenne keine Zahlen, vielleicht weißt ihr jemand was, aber auch im WordPress Score und in vielen Plugins wird natürlich viel mit JavaScript gearbeitet. JavaScript läuft im Klein, läuft auf dem Server und ich glaube, da würdet ihr mir recht geben, so das Gefühl, das kommt, kommt immer mehr, ist schon da. Ich weiß nicht, vielleicht die ersten Rückmeldungen, was für ein Gefühl habt ihr? Geht JavaScript übermorgen weg, arbeitet ihr in 3 Jahren noch damit, was ist eure Idee? Gibt es 5 neue Frameworks, das kann gut passieren, gut. Andere Meinungen, wer von euch entwickelt JavaScript, was macht ihr? Okay, cool. Die anderen? Okay, auch gut. Also meine Wahrnehmung JavaScript ist da und lohnt sich damit auseinanderzusetzen. Der nächste wichtige Punkt beziehungsweise, warum ich mich mit dem Thema Testing beschäftigen will, mir geht es oft so irgendwie testen, gerade auch automatisiertes Testen, Test schreiben ist für mich eine große Herausforderung. Ich finde es nicht einfach und immer wieder schwierig und deswegen aber sehr interessant, weil ich finde immer da, wo irgendwie eine Herausforderung ist oder wo ich selber persönlich hängen bleibe, lohnt sich es oft mal hinzugucken, was da eigentlich los ist und deswegen habe ich da Lust, mich damit zu beschäftigen. Kennt ihr das? Sogenannte Mind Behavior Gap, wenn man sich irgendwie mit Leuten über moderne Softwareentwicklung unterhält und fragt, ja, was macht ihr? Wie macht ihr das? Kommt man bestimmt oft dahin, ja klar, Test first, Test driven Development, wenn man sich dann mal mit den Leuten bei zwei Bier unterhält. Ja, finde ich eine gute Idee, aber so im Alltag ist es schwierig umzusetzen. Ich weiß nicht so richtig, dauert so lange Zeit, gibt es einen ganz tollen Begriff auf den Model-based Systems Engineering, das nennt sich Frontloading, also da geht es eigentlich darum, wo verbrauche ich eigentlich meine Zeit. Natürlich, wenn ich anfange, Test driven Development zu machen, dann brauche ich am Anfang erstmal Zeit, bevor ich irgendwie überhaupt was sehe und muss ziemlich viel klären, komme ich auch später nochmal, bevor ich überhaupt anfangen kann zu entwickeln, dann wird sozusagen halt am Anfang von dem Prozess sichtbar, wie viel Zeit das braucht, in anderen Prozessen dann am Ende oder diese Kurve, wie teuer es ist, ein Bug zu fixen in der Entwicklung oder dann in der Produktion, kennt ihr sicherlich, da ist so ein Faktor 1000 oder so, von dem her ist das ein spannendes Thema, aber hier so meine Wahrnehmung, alle sagen oder viele sagen, ja, wir entwickeln Test getrieben oder beschreiben zumindest mal Unitests vielleicht auch hinterher, aber wir haben das und wenn man dann in die Praxis geht oder man fragt, ja, zeigt mir doch mal euren Code Coverage Report, dann wird es schwieriger und mir persönlich geht es genauso. Also wie gesagt, ich bin da mit drin und schwimm damit, ich möchte es gerne machen, ich weiß, dass es gut ist und gleichzeitig ist es nicht so was, zack, da ist es und ich mache das nächste. Es ist natürlich die Frage, warum will ich überhaupt testen? Was bringt mir das? Also ein Test, da hat kein User was von so, das schafft keinen Wert in dem Sinne. Eure Ideen würden mich interessieren. Das ist eine gute Idee, dass Test eine gute Idee ist. Genau, also einfach Reproduzierbarkeit. Also wenn ich sage, hier testen meine ich einen automatisierten Test, wie auch immer der dann geartet ist. Du hast gesagt, du entwickelst JavaScript, schreibst du automatisierte Tests für JavaScript, interessanter Punkt, ja, sind sonst Entwickler hier, vielleicht auch PRP Entwickler, testet ihr automatisiert? Es macht den Code besser. Es macht den Code besser. Also wirkt sich irgendwie auf das Design, also auf Software-Design oder auf der Architektur gegebenenfalls aus. Okay, weitere Ideen. Dann hat man schon das Thema Flexibilität, ich kann Software irgendwann nicht mehr ändern, wenn ich keine Tests habe. So der erste Punkt, wo ich drauf gekommen bin, ist irgendwie so Sicherheit. Ich mache eine Änderung und will irgendwie wissen, oder die Frage kommt auch, ja, geht jetzt noch alles, ja, ich muss Plug-in-Updaten bei WordPress oder in Theme, ja, gehen, geht da noch alles. Ich sage, okay, ich habe ein Sicherheitsbedürfnis, okay, ich bin Entwickler, ich will irgendwie alles kontrollieren. Ich bin einfach ein Schisser, also kontrollfreak und passt. Und dann habe ich irgendwie weitergedacht und habe mir so gedacht, weil es gibt ja so den Ausspruch, so no risk, no fun, so entwickeln auch manche Leute, die sagen einfach, ich schreibe die drei Zeilen rein, das ist mein Projekt, das ist mein Baby, das betreue ich seit drei Jahren, da geht nichts kaputt, ich kenne jede Zeile. Und sagen so, wie gesagt, no risk, no fun, erzähle, das war ein Junior-Developer, der irgendwie seit einer Woche in der Firma ist, dem geht es ganz anders. Und ich bin dann irgendwann hierhin gekommen und habe irgendwie doch vielleicht gesagt, no risk, no pain. Also wie wäre es denn, wenn man sich sozusagen mal die positive Seite anguckt? Was könnte dann passieren, wenn ich einfach sagen kann, ja, ich baue jetzt meinen Code ein bisschen um, weil der könnte schlanker oder besser lesbarer sein. Und weiß aber gleichzeitig, dass noch alles funktioniert, finde ich eine super Idee. Und das habe ich dann noch sozusagen ein bisschen maximiert und gesagt, no risk, no potential. Also sozusagen, es gibt zum Beispiel eine positive Psychologie, die beschäftigt sich nicht mit dem Problem, sondern sozusagen mit den Potenzialen. Und da sehe ich beim Thema Testen auf jeden Fall ein Potenzial. Ich will hier ein kleines Zitat vorlesen. Dein Potenzial entfaltet sich natürlich, wenn du dich sicher fühlst, klar bist und dich für etwas begeisterst. Und dieses Sicher fühlen kann mir ein gut getestetes Projekt geben. Das heißt, ich kann damit weiterkommen. Und also mir als Entwickler geht es auf jeden Fall so, wenn ich im Projekt bin, wo ich eine gute Testabdeckung habe, so dann sage ich mal, steigt meine Developer-Happiness. Das mache mir Spaß. Und ich meine, gerade in unserem Bereich, es gibt viele Firmen, es gibt viel Arbeit. Arbeitgeber probieren sich auch zu positionieren, geben ihr Mitarbeiter Massagen, geben irgendwelche Benefits Sport und so. Und das könnte für mich auch in dem Bereich fallen. Also so bei Stack Overflow gibt es bei den Shop-Angeburten so einen 12-Punktenplan, wo Firmen sagen können, wie viel sie davon erfüllen. Da ist so Continuous Integration und Test Driven Development auf jeden Fall ein Punkt. Und auch so ein bisschen eine kätzlerische These. Was haltet ihr von dem Ziel? Ich habe gerade Zeit, wo gibt es nichts zu tun. David Hansmeyer Hansen von der Rails ursprünglich mal mitentwickelt hat, oder auch überhaupt diese Leute von 37 Signals, die sagen auch so was wie, wenn du die ganze Zeit beschäftigt bist, dann stimmt irgendwas nicht. Ein starrer, guter Entwickler arbeitet nicht so viel. Der hat Zeit für was anderes. Und genau, so in die Richtung geht das halt. Also wenn ihr die ganze Zeit beschäftigt seid, macht ihr irgendwas falsch so. Wir sind immer noch beim Thema, warum habe ich eigentlich das Bedürfnis zu testen oder warum ist es wichtig? Hier ein Klassiker. Die einzigste Konstante im Universum ist die Veränderung. Wenn man das Zitat googelt, findet man ziemlich viele Quellen. Ich habe einfach mal hier den krisischen Philosoph rausgegriffen. Und gut zu dem Thema Softwareprojekt, was älter ist, ohne Test, kann ich irgendwann gar nicht mehr weiterentwickeln, weil es einfach viel zu teuer wäre, das jedes Mal wieder manuell durchzutesten. Also ohne automatisierte Tests, meine ich. Okay, da war ich so Sicherheitsbedürfnis, Developer-Happiness, Flexibil, also Änderung machen und irgendwie einfach nicht so ganz zufrieden. Ich habe überlegt, ja, warum geht es hier noch oder warum fühle ich mich zum Thema Testen hingezogen. Warum beschäftige ich mich damit und will eine Session drüber machen. Und dann bin ich sozusagen ein bisschen auf die Meta-Ebene gekommen und habe gesagt, eigentlich geht es bei so einem Test um ziemlich, um Klarheit. Also wenn ich festlege, also vor allem in einem Unit-Test, das ist sozusagen mein erwarteter Outcome und das ist das, was gerade rauskommt, dann bin ich extrem klar. Und Klarheit ist was, was ich immer wieder in Software-Entwicklungsprozessen sozusagen vermisse. Das ist auch völlig okay, da kommt irgendjemand, der hat eine Anforderung oder der hat eine Idee. Aber das ist eigentlich das, was für mich ein Test auszeichnet. Der sagt auf ganz kleiner Ebene, der ist sehr, sehr klar, was jetzt eigentlich sein soll und was gerade ist und vergleicht das gegeneinander. Also das ist auf jeden Fall ein Punkt, der sozusagen auf weiter Ebene für mich beim Thema Testen mit reinkommt und das ist auch was, was mir persönlich sehr wichtig ist. Ich will einfach klar sein und wach. Dann haben wir eben schon drüber gesprochen, das Thema Flexibilität. Ich will Änderungen machen können. Ich will vielleicht auch mal irgendwie ausprobieren und geht auch vielleicht ein bisschen in anderen Bereich, aber das können wir auch wieder gut auf Software-Entwicklungen, Online-Marketing. Ihr kennt das sicherlich irgendwie, wenn man AB-Tests macht, ich vergleiche zwei Landing-Pages gegeneinander, guck mal, ob der grüne Button besser performt oder der rote. Es geht einfach darum, zu experimentieren und auszuprobieren. Und wenn ich halt ein Projekt sozusagen automatisiert getestet habe, dann habe ich eine Basis, um das tun zu können. Es gibt auch so ein schönes Zitat, Play is not a game, Play is a state of being. Also klingt jetzt erstmal ein bisschen blöd, aber ich lade euch einfach ein bisschen rumzuspielen. Und wenn man automatisiert testet im Projekt, kann man das machen, kann man mal eine blöde Idee ausprobieren oder irgendein Feature reinbasteln, merkt an, nee, das macht jetzt drei Sachen kaputt, ich nehme es wieder raus und die bläut nicht, kriege ich morgen Anruf, da ist ein Bug, da geht was kaputt, das kostet Geld. Also genau die andere Sache. Und der letzte Punkt, habe ich nochmal Developer Happiness aufs nächste Level gehoben, habe ich so gesagt Developer Resilienz. Also was macht eigentlich ein Developer sozusagen stark oder also Resilienz definiert sich bei Wikipedia so psychische Widerstandsfähigkeit, Fähigkeit Krisen zu bewältigen und durch Rückgriff auf persönliche und sozial vermittelte Ressourcen als anders für Entwicklung zu nutzen. Also es ist einfach für mich eine wahnsinnig gute Basis, um tolle Software zu entwickeln, wo der Prozess auch noch Spaß macht. So, jetzt habe ich gesagt, warum es aus meiner Sicht Sinn macht oder warum ich das Bedürfnis habe zu testen. Hab mir gesagt, wir wollen auch was machen hier. Hab mir mal den Slide eingebaut, leg endlich los. Schreib so einen verdammten Unit Test. Die ganze Session heißt der Unit Test React. Das heißt, ich möchte nochmal kurz darauf eingehen, was React eigentlich ist. Hab hier ein Screenshot gemacht von der React Seite. Also, die sagen selbst JavaScript Library for Building User Interfaces und hier sind immer so drei Punkte, die sozusagen React auszeichnen. Ich weiß nicht, arbeitet jemand von euch mit React? Ja, was machst du? Wozu setzt du das ein konkret? Okay, dann glaube ich sprechen wir über was anderes, weil also es geht sozusagen um Unit Tests für React, aber die eigentliche Library, die ich sozusagen hier vorstelle und verwenden will, dass es sozusagen eine Library um Interfaces zu bauen. Das hat jetzt erstmal direkt nichts mit dem Test zu tun, sondern das ist sozusagen das, was ich habe. Und das test ich dann. Also, React ist, wenn man von einem MVC-Modell kommt, sozusagen könnte man sagen, das ist der View Layer. Also, ich habe irgendwelche Daten und will die, ja doch auch strukturieren, ist schon ein wichtiges React und einfach darstellen. Um alles andere kümmert sich React nicht. Also, es ist kein volles Framework, also lässt sich jetzt nicht irgendwie mit Angular oder Ember vergleichen, sondern nur mit dem View, mit dem das sozusagen wie das dargestellt wird vergleichen. Dann, was interessant ist, in React gibt es einen Virtual DOM. Einzelheiten müsst ihr euch selber erarbeiten, da bin ich auch noch nicht so tief drinne, was sozusagen rauskommt, für den User im Endeffekt ist. Ich kann ziemlich performant halt meine Seite updaten, weil die haben diesen Virtual DOM und machen dann sozusagen die Unterschiede zu dem echten DOM halt. Die packen das zusammen und updaten das sozusagen schlau. Das funktioniert ziemlich gut. Das heißt, es ist eine schöne Performance und genau, es ist schnell. Und was React auch noch ausmacht, ist sozusagen jetzt endlich die Philosophie, wie der Datenfluss funktioniert. Bei Angular zum Beispiel habe ich ja so ein Two Way Data Binding und die haben halt sozusagen einen direkzionalen Datenfluss. Jetzt habe ich vergessen zu klicken. Genau, das waren die drei Sachen, die ich gerade durchgesprochen habe. Das ist ein wichtiger Punkt, das ist auch für das Hands On jetzt wichtig. In React als View Layer sind eigentlich alle Elemente Komponenten. Und so eine Komponente ist immer ein Fierig. Hier gibt es einen schönen Artikel in der Dokumentation von Pete Hunt, der beschreibt halt, wie man mal, wie man eine statische Seite sozusagen in React Komponenten aufteilt, wie die sich das gedacht haben. Und hier links ist einfach so eine Liste mit einem Suchfeld und hier ist das Beispiel, wie das sozusagen in diese Komponenten jetzt visuell dargestellt, aufgeteilt wird. Das so zu der Idee, ich vergleiche das immer so ein bisschen wie, keine Ahnung, wenn ich was in CSS machen will, dann habe ich auch im Endeffekt überall vier Ecke drum. Das hilft mir eigentlich ganz gut. Genau, was auch noch wichtig ist, wenn wir jetzt einen Unit Test schreiben wollen, wie ist der eigentlich aufgebaut. Und da folge ich einer gewissen Person, sehr gerne, das hier ist Eric Ayert, ein JavaScript-Entwickler in den USA, der veröffentlicht ziemlich viel Lernmaterial und tut ziemlich viel schreiben. Und ja, das ist sozusagen mein selbst ausgewählter Mentor, weil ich einfach denke, es ist wichtig in unserer Branche, wo viel passiert, man kann nicht alles erfassen und muss irgendwelche Filter vorschalten und ich mache das einfach so, dass ich gut finde. Und er ist jemand, zum Beispiel, er bezieht ganz klare Meinungen, argumentiert das dann auch, aber sagt sozusagen, das würde ich so machen und das würde ich nicht so machen. Und so probiere ich halt zu lernen, das ist mein Ansatz, mich auch weiterzuentwickeln. Wie handhabt ihr das? Ich finde ich ganz wichtig im Bereich Online, weil da in Anführungsstrichen viel passiert. Das sind eure Lernstrategien, wie bildet ihr euch weiter? Okay, ja, das ist schon mal eine super Idee. Bist du so jemand, der selber auch Github-Projekte zum Beispiel veröffentlicht, also Spielprojekte? Ja, was machst du da zum Beispiel? Es ist jetzt eine persönliche Interesse. Frage, wie machst du das mit der Zeit? Baust du das in deine Arbeitszeit ein oder sind das irgendwie deine Freizeiten des Abendstunden, machst du das am Wochenende? Vollzeit. Vollzeit Github-Player. Okay, cool. Schön, das ist schon mal gut. Genau. Und so mache ich das halt. Und Eric hat halt eine Artikel geschrieben, 5 Questions, every unit test, machst answer. Und das gehen wir jetzt einfach mal kurz durch, weil wir wollen ja gleich schreiben. Also erstmal soll mir der Unit-Test natürlich Aufschluss darüber geben, was für eine Komponente, also das ist jetzt schon mal direkt auf React bezogen, wird eigentlich getestet, aber man könnte auch sagen, was für ein Modul oder was für eine Einheit test ich eigentlich. Dann, welches spezifische Verhalten wird getestet? Das heißt, ich gucke mir eine kleine Sache davon an, will ich auch aus dem Test lesen können. Dann geht es darum, was ist der aktuelle Output, also ich führe den Test aus und irgendwas kommt raus, muss ich auch festlegen. Und was ist mein erwarteter Output? Was soll rauskommen? Und das ist letztendlich da, was der Test macht, der vergleicht den aktuellen und den erwarteten Output und was auch noch wichtig ist, wie kann das Testergebnis reproduziert werden? Das ist auch manchmal gar nicht so einfach, aus den Tests rauszulesen. Okay. Dann ist auch von Eric Elliott sozusagen, der, finde ich ganz cool, hat gesagt, Experience-Testing-Send. Wenn ich automatisierte Tests machen will, muss ich mich auch mal entscheiden, was ist sozusagen mein Testrunner, in welcher Umgebung führe ich das aus, so wie es schon gesagt hat, es kommen jede 3 Tage 5 neue Frameworks raus, da gibt es total viel. Ich benutze Tape, das ist ein ganz kleines Tool sozusagen, das kann gar nicht viel und hier steht auch nochmal, warum das eine gute Idee sein kann. Sich da sozusagen auf das Minimale zu konzentrieren, damit man mich die Zeit nicht damit verbringt, seinen Test-Tool zu konfigurieren, weil wie gesagt, die Tests an sich bringen dem User keinen Mehrwert am Ende. Zumindest nicht direkt. Okay. Das Testprojekt, wo wir ein Test verschreiben wollen, das heißt Synagy. Das ist einfach meine Idee, immer wenn ich unterwegs bin, oder auch bei uns zu Hause oder so, ich treffe irgendwie jeden Tag neue Leute, komme mit denen in Kontakt, kann mir das aber gar nicht merken, wen ich alles getroffen habe und oft habe ich das Gefühl, ich habe irgendwie eine Herausforderung oder suche irgendwas bestimmtes und eigentlich ist da irgendwo jemand, der das haben könnte, aber ich habe es einfach vergessen und das kann man jetzt glaube ich nicht so gut lesen. Ich sage so, wer ist das? Peter ist Musiker, wohnt in Berlin und wenn ich irgendwie jetzt zu Besuch in Berlin bin und ein Konzert machen will, dann wäre es eine gute Idee, den anzurufen. Das ist so die Idee, ist wie gesagt ein Spielprojekt. Ich habe hier so ein Boilerblade genommen, R3 Foundation heißt das, da sind noch andere Sachen drinnen, Redux und React Router und halt als Frontend Style Framework Foundation. Da wird jetzt noch viel drumherum sein, darum geht es jetzt aber nicht. Wir schauen uns wirklich die React Komponenten an. Genau, damit fangen wir jetzt an. Ich muss den Monitor umschalten, damit der synchronisiert ist und dann machen wir das einfach mal. Hier ist es ein bisschen unscharf, aber ein bisschen schärfe Klarheit. Könnt ihr das erkennen oder ist es schwierig zu lesen? Weil ich gucke hier jetzt auf dem Bildschirm. Also vom Prinzip her, wie gesagt, da ist jetzt noch viel drumherum, das werde ich jetzt nicht irgendwie alles erläutern können, weil es einfach zu viel ist. Ich führe sozusagen Tape immer dann aus, wenn sich irgendwie die Datei ändert. Das läuft hier und da gucken wir dann sozusagen auch immer, wenn die Tests sozusagen fehlen, beziehungsweise dann auch passen. Es gibt so ein kleines Mantra in der Teststream Development, wo man sagt halt Fail Pass Refactor. Das heißt einfach, wenn ich meinen Test zuerst schreibe und meine Komponente noch nicht habe, das geht erstmal nicht. Dann schreibe ich meine Komponente, dann pässt mein Test und dann habe ich die Möglichkeit, weil es halt getestet ist, zu Refactern meinen Kot halt besser zu machen, wenn ich dann die Notwendigkeit sehe. Genau, hier läuft noch ein anderes Skript, das macht sozusagen den lokalen Server hier für das Projekt Localhost. Genau. Vom Prinzip her, was wir machen wollen und das zeige ich gleich hier drumherum, ist jetzt eine große React Komponente. Das ist die Person List sozusagen und jeweils hier ist halt sozusagen eine Person drin. Und jetzt ist es so, dass, als muss ich vorher sagen, ist immer gefährlich eine mit Live Coding, da geht meistens was schief, aber ich mache es trotzdem. Genau, das hier ist sozusagen die React Komponente, die Person und was wir jetzt endlich machen wollen, hier steht jetzt sozusagen das Markup hier direkt drin in der Komponente, wir wollen jetzt hergehen und zum Beispiel für den Namen wirklich mal eine Komponente raus extrahieren, weil ich die Unit testen will. Ich will gucken, geht meine Namenskomponente. Das könnte ich hier jetzt gerade nicht auf Unit-Ebene machen, weil ich da sozusagen die ganze Person drumherum hab und das ganze machen wir je nachdem, wann ihr einschlaft bis zu maximal 4 mal, weil durch Wiederholung lernt man. Also, wir haben gesagt, wir wollen Test First machen. Ich hab hier ein Test Verzeichnis und hab hier ein Test, das ist sozusagen ein Blueprint für eine Komponente. Da gehen wir mal kurz durch, was da drinnen los ist. Ich importiere halt hier oben. Ich weiß nicht jetzt genau, auf welchem JavaScript-Level ihr seid, in welcher Umgebung. Das hier ist IS6. Das heißt, ich kann Module importieren. Den Code kann ich momentan noch nicht im Browser ausführen, den muss man transpilieren. Das heißt, nochmal umrechnen, sodass ein aktueller Browser interpretieren kann. Aber dafür gibt's halt Babelmachters, dass dieser Transpiler, und das funktioniert ziemlich gut bis der Code direkt im Browser ausführbar ist. Also, ich will React-Testen. Also, brauche ich meine React-Library. Dann brauche ich React-Dom. Erklär ich gleich, warum. Wir sind im anderen Paket drinnen. Dann Test-Tape, das ist das kleine Test-Tool, sag ich mal, was ich vorgestellt hab. Und Cheerio ist Utility, was so eine relativ ähnliche JQuery-RP hat, um mit DOM-Elementen zu interagieren. Ich mach das anders, weil das so krieg ich einen steifen Nacken. Also, es geht hier oben, also nochmal um den Rahmen zu schaffen, das ist jetzt sozusagen mein Muster für einen Unitest, der diesen fünf Fragen folgt. Es geht natürlich hier oben los. Hier importiere ich die Komponente, die ich eigentlich testen will. Das heißt, ich bin ja gerade im Test-File. Hier hole ich mir die Komponente rein und hole mir hier eine Renderfunktion von React-Dom. Das ist sozusagen dafür wichtig, weil die Komponente ist ja letztendlich React-Context HTML. Und um das sozusagen in den String zu bekommen und auch testen zu können, also das, was letztendlich im Browser auch passieren würde, das passiert da drüber. So, hier Antwort Nummer eins. Welche Komponente wird getestet? Wie gesagt, das ist eine boilerplate My-Komponent. Welchen speziellen Aspekt oder welches spezifische Verhalten von der Komponente will ich testen? Schreibe ich hier rein. Dann habe ich hier eine Message. Da geht es einfach darum, dass da steht, was halt passieren soll. Schon du, genau. Und jetzt muss ich mal ganz kurz gucken, dass ich das gut erkläre. Machen wir hier weiter. Hier habe ich letztendlich meinen Element. Das ist meine Komponente, die ich testen will. Hier Komponent Blueprint, die habe ich hier oben importiert. Und dann muss ich das halt hier einmal rendern. Und dann habe ich meinen Output, also was ist letztendlich rausgekommen. Das ist der Teil, was ist der aktuelle Output, Punkt 3. Ah nee, das ist erstmal der HTML Output. Hier ist es sozusagen nochmal, wird halt mit der regular expression geguckt, ob das, was ich erwartet, da drin ist. Das ist hinterher für den Test Output, das ist interessant, weil halt geguckt wird. Ob letztendlich der Value, das wird gleich konkreter in dem HTML drin ist, was React gerendert hat. Genau. Das ist der actual Output. Das ist das, was ich erwarte. Ja, ich erwarte, dass mein Value, den ich hier oben definiert habe, in dem gerenderten Output hier, beziehungsweise als HTML hier drinnen ist. Und das ist letztendlich das, was ich von Tape dann wieder kriege, dieses Assert, Equal. Und da vergleicht das halt und gibt die Message von hier oben aus. Weil ich das ja jetzt auch vorbereitet habe und dreimal diesen Test geschrieben habe, mir ist das alles klar. Fragt jetzt gerne eure Fragen. Ich würde es glaube ich nicht verstehen, wenn es mir jemand so präsentieren würde. Also darf jegliche Frage sein, ihr könnt einfach sagen, besudel mich weiter, dann mache ich weiter. Genau, es wird, View ist für mich keine Struktur, sondern es ist halt die React Komponente. Genau, die Komponente. Und das ist im Endeffekt einfach, dass HTML, was halt rauskommen soll. Also das hier will ich im Endeffekt ja testen. Genau. Ja, genau. Ein Stückchen HTML, in dem ich dann letztendlich ja einen String suche in dem Fall, ob der da ist oder nicht. Weil der React Komponente macht auch eigentlich nicht mehr. Also das ist jetzt ein Element, was ich herausgegriffen habe, aber das ist so das Key-Element und mehr passiert er eigentlich auch nicht. Genau. Weitere Fragen zu diesem Test Blueprint. Irgendwas, was unklar ist oder sich irgendwie blöd anfühlt, was würde ihr anders machen. Sieht das viel aus für ein Mini-Test. Also ich finde es eine gute Idee und ich bin auch jemand, der eher mehr Code schreibt, dafür, dass es irgendwie leserlich ist. Ich bin nicht jemand, der es irgendwie probiert, aufs letzte Zeich zu optimieren, nur damit es genial ist. Also ich kenne das auch, das macht irgendwie Spaß, wenn man einen Short-Hand für irgendwas hat. Aber, damit ich selber in drei Wochen wieder verstehe, schreibe ich es gerne ein bisschen länger aus von Studenten und Klassen eher, glaube ich, zu langen benennt. Deswegen finde ich das eine gute Idee. Natürlich ist das sozusagen abgeleitet aus diesem Artikel hier auch, der natürlich der probierte Best Practice halt darzustellen. So ein bisschen so eine Gradwanderung. Genau. Ja, genau. Das ist halt so ein bisschen der Sache geschuldet, dass man halt einfach sagt, wenn mein Test fehlt, habe ich halt eine Art-Bug-Report schnell verstehen, weil letztendlich ein Test der Pest, der bringt dir nix. In dem Sinne bringt dir schon was, aber in dem Fall, wenn er halt sozusagen fehl schlägt, willst du ja natürlich wissen, warum. Und das hilft dabei einfach. Also ein bisschen sprachlich dazu machen. Du würdest es kürzer schreiben. Du würdest es kürzer schreiben, du würdest hier unten direkt reinschreiben. Okay. Okay. Ja, habe ich jetzt hier in dem Projekt ein paar Teile sein darf soll. Machen wir mal so ein bisschen so. Diese Kommentare habe ich jetzt halt speziell auch zur Erklärung, was überhaupt passiert, weil das so ein bisschen rekt hintergrund bzw. wie man es halt testen kann. Genau. Dann alle Klarheiten beseitigt. Dann fangen wir an, den Test zu schreiben sozusagen. Ich kopiere mir hier den Blueprint und dann ein Test schreiben für eine Komponente, die noch nicht existiert, weil wir Test First machen, aber es geht hier um Name und die Komponente wird einfach Name heißen. Den findest du in ähnlicher Form in diesem Artikel. Genau. Du wirst es einbubeln, der reicht aber auch erstmal. Genau. Dann ist hier nur die Index-Datei damit der Test auch gleich ausgeführt wird und dann geht es sozusagen los. Also ich will eine Komponente testen, die es nicht gibt, die importiere ich als Name und die liegt halt in den Komponenten, also das eigentliche React-File. Speicher das und genau, das ist sozusagen jetzt Test First Live. Das ist für den Test aus, der fällt, weil das Modul gibt es nicht. Er sagt halt hier find module. Als nächstes würde ich vielleicht hier noch kurz die boilerplate-Namen anpassen, also die Namenskomponente will ich testen mit Name-Prop. Jetzt erzähle ich gleich nochmal kurz was zu React. The name of the person. Bei React ist es so es gibt die sogenannten Props, also das letztendlich meine Daten, mit denen ich arbeiten will und diese Props, die es schwierig auf Deutsch irgendwie zu formulieren, die passig, also die gebe ich sozusagen in der Komponentenherarchie runter, also wenn ich hier meine Personenliste hab, also drumherum stellt euch ein 4-Eck-Trummer rum vor, das ist meine Liste und da sind jetzt 3 Personen drin und jede Person hat ein Name, eine Location und irgendwie ein Tag, dann gibt diese Liste diese Prop, also was halt eine Proparty ist, halt an die jeweilige Komponente das kann man mal schauen, finde ich gerade nicht, machen wir hier weiter. Genau, also das will ich testen Namen Komponente mit der Name-Property was soll da rauskommen der Name der Person. Klingt jetzt erstmal ziemlich einfach und vielleicht auch ein bisschen dumm, aber im Endeffekt ist das so, wenn ihr euch eine Test anguckt, genau darum geht's, ist ganz einfach und gleichzeitig ganz klar, das ist das Thema, was ich hier vorher gesagt hab, wenn man das hat und dann fragt sich jemand in 2 Monaten, ja, wie war das, warum haben wir das so und so gemacht oder wie soll das eigentlich sein, gibt keine dokumentierten Requirements, dann kann man da ziemlich gut reinkommen und sagen, ja, okay, da wird halt eine Proparty erwartet, das ist der Name und über die Handynummer haben wir offenbar nie gesprochen. Also das finde ich immer so noch ein interessantes Aspekt. Also haben wir nie darüber gesprochen, das stimmt jetzt auch nicht, weil vielleicht ist es auch nicht im Test gelandet, aber ihr wisst, worauf ich hinaus will. So, genau, also den Value suche ich letztendlich, Peter, der Komponente gebe ich hier, deswegen muss ich das hier auch machen, mein Pops-Object, das soll letztendlich ein Key haben, der heißt Name und Value steht halt der Name drin, Peter und mein Element sondern das ist meine Name Komponente und das hier ist jetzt sozusagen auch wieder React. Ich gebe dir halt die Props hier, das ist das Objekt und speichere das Ganze. Dann kann ich mir wieder nach dem Mantra meine Tests angucken, kann die Komponente immer noch nicht finden, weil wir sie noch nicht angelegt haben, das mache ich jetzt mal, ich bin jetzt hier oben in meinem Source Folder, das ist wie gesagt die Struktur von dieser Boilerplate, habe ich auch ein Blueprint angelegt, das ist letztendlich, es gibt in React, sprich man von sogenannten Smart Komponenten, die werden auch Container genannt und es gibt Dump Komponenten, also sozusagen Dummel Komponenten, das ist jetzt eine Dumme, der gebe ich einfach irgendwelche Daten und die stellt die da, die weiß nichts anderes. Die kopiere ich, nenne die so wie ich will und genau, speichere das ab und würde jetzt erwarten, dass er das Modul findet, das macht er auch, also hier unten geht es jetzt sozusagen weiter mit dem Test, die werden immer neu ausgeführt, wenn was geändert wurde und der findet hier das, was wir geschrieben haben, das Name Prop, aber der Test fehlt halt noch aus verschiedenen Gründen, jetzt passen wir den erstmal an, gucken hier unten, wahrscheinlich wird im Output die Klasse von dem HTML Element auch nicht mehr myKomponent sein, sondern die nennen wir Name und hier den Key von der Property haben wir schon angepasst, Test fehlt immer noch und jetzt müssen wir das hier noch in der Komponente, also in der ReactKomponente letztendlich anpassen, weil mein Test, da ist jetzt sozusagen eine Abhängigkeit, der holt sich ja das HTML Element mit der Klasse Name und das ist jetzt auch nicht mehr myKey, sondern das ist Name und damit sollte der Test durchlaufen, hier bitte, da da ist gerade was verrutscht, danke genau und dann hier unten Name mit NamePop läuft durch was ich so irgendwie gefühlt auch ganz spannend finde es hat überhaupt nichts damit zu tun, weil das ist ja einfach mein Test der ist losgelöst von der Seite der importiert selber die Komponente alles los voneinander losgelöst die Person Komponente hier die hat nach wie vor unser ja, unser statisches HTML sozusagen hier drin, 10 Minuten gut, da machen wir nur eine Komponente also passt gut auf, keine Wiederholung das können wir jetzt natürlich noch ändern, indem wir hier oben die neu angelegte Komponente die jetzt auch geunet testet ist importieren und hier jetzt als Komponente halt ausgeben Name dieses PropsName kommt von der PersonList, wird sozusagen von oben runter gegeben und ich mach das ganze Ding noch zu hier wollen wir das HTML keinen Paracraf, sondern Headline 4 haben, genau ein Zieb her, hier kommt jetzt genau das gleiche raus, man sieht keinen Unterschied aber wir haben halt gewonnen dass wir diese Komponente isoliert unit testen können genau, das muss man sich jetzt auf der Zunge zergehen lassen weil im Endeffekt ist es das, natürlich, normales Projekt hat noch tausend andere Sachen theoretisch, habt ihr jetzt gesehen wie man das halt in so einem Rahmen machen kann und ihr könnt jetzt alle unit tests schreiben für React also, das ist auf jeden Fall super war nur Spaß, ihr habt eine Idee davon, wie das aussehen kann und vielleicht ist es für den ein oder anderen auch mal die Matrix sozusagen aufgehoben, also das ist das ist so wie es ist ok andere Komponenten lassen wir so ich habe eben ein Schild gekriegt, dass ich noch 10 Minuten habe deswegen mache ich weiter ich mache wieder den Synchronisation aus, damit ich meine Notizen habe und weiß, was ich erzählen will das hatte ich eben schon mal anklingen lassen, warum unit tests inklammern ich habe gesagt, ok, auf der einen Seite unit testsen finde ich gut, macht Sinn sind schnell, kann ich portieren und ich bin auch immer ein Fan von end-to-end test, das heißt wirklich ein Browser zu automatisieren, weil ich finde das ist das nächste, was sozusagen der User bekommt ich weiß ja jetzt, meine Komponente funktioniert aber es können auch tausend andere Sachen in meiner App kaputtgehen sozusagen und da gibt es ein schönes Testrunner der heißt Nightwatch ist halt auch in JavaScript geschrieben und der testet letztendlich gegen Selenium Instanz wer von euch hat schon mal einen Selenium Test geschrieben ja wie sind eure Erfahrungen nicht besonders warum nicht test first der Test geändert, bevor der Code geändert ist es ist natürlich Arbeit und es ist auch in Anfangssprich noch erstmal mehr aber zum Thema Frontloading also wo wird die Zeit verbraucht oder Test schreiben dauert gerade so lange aber wenn man sich anguckt was Software-Entwicklungsprozessen anderes so lange dauert dann finde ich das ein ganz guten trade-off also Nightwatch Browserautomatisierung zeige ich auch einfach nur nochmal ein mini Beispiel ist jetzt ein ganz kleines was ich aber finde, gerade auch zum Thema React, also es geht um Userinterface da wirklich gut ist weil sowas wie zum Beispiel ich klicke ich stelle nochmal meinen Monitor um, dann rede ich weiter kann ich beides gleichzeitig also ich klicke jetzt zum Beispiel hier oben sowas kann ich jetzt nicht direkt, also natürlich kann ich es irgendwie auch unit testen aber das würde ich persönlich nicht unit testen, sondern das finde ich einfach ein klassischer end-to-end test dass ich da wirklich mal draufgegründ weiß das dann auch was kommt zu das gibt mir nochmal einen ganz anderen Aufschluss und das sieht in Nightwatch dann einfach so aus letztendlich sage ich hier auch wieder was für eine Komponente, meine Komponente ich gucke nach einer CSS-Klasse im HTML beziehungsweise prüfe halt ob die da ist und gib dann eine Message aus und hier sage ich, ok ich will mal die Not-Found-Page testen damit habe ich weiß ich auch irgendwie dass mein routing so funktioniert auch für den End-User ja, fünf Minuten haben wir noch schön klickt da sozusagen auch wieder auf eine Klasse das ist wahrscheinlich das wo du meintest, das ändert sich oft da wenn jemand die Klasse ändert im Code, dann schlägt der Test fail und die Applikation geht vielleicht noch schlägt fail, schlägt fail und dann gucke ich wieder ob ein Text da ist gucke noch einen anderen Text und dann mache ich das ganze wieder zu und wie gesagt Selenium-Server muss laufen hier an und dann kann ich meinen Test einfach mit Nightwatch sozusagen ausführen und der startet mir dann halt wirklich ein Browser geht da drauf, macht seinen Assertions und gibt mir das Ergebnis das Spannende ist es wieder automatisiert, das heißt ich kann das jetzt auch nehmen, irgendein Service geben houselabs, testet das mal in den letzten drei IE-Versionen durch oder ich könnte hier auch ein Headless-Browser benutzen, PhantomJS ein bisschen schneller also dadurch dass ich es ja replizierbar hab kann ich es wieder spannend in verschiedenen Umgebungen halt laufen lassen zum Beispiel Screenshots machen ich arbeite manchmal mit Codeception ich habe eine schöne neue Funktion der macht zum Beispiel bei jedem Schritt ein Screenshot dann habe ich hinterher einfach so eine Slideshow durch mein Test durch, finde ich so persönlich als Ergebnis geil irgendwie könnte man auch super im Kunde geben also ja das finde ich Thema Unitests, Funktionale End-to-End-Tests Beispiel JavaScript Nightwatch gibt es tausend andere Lösungen ich finde die gut und wollte ihr euch ganz kurz zeigen Vielen Dank, ich bin durch