[Musik] testen mit the unit bevor wir in das testen mit unit einsteigen möchte ich noch ein paar begriffe nachtragen die wir beim allgemeinen einführen des thema testens noch nicht angeschaut haben die aber gerade dann wenn wir im kontext von the unit tests über tests sprechen doch sehr hilfreich sind weil sie doch unterschiedliche arten und vorgehensweisen des testens anreißen und diese begriffe sind black box und white box test und auf der anderen seite positiv und negativ test beginnen wir mit dem black box test dabei geht es um das prüfen der schnittstelle wir wollen also von außen eine blackbox betrachten dessen inneres wir nicht sehen können und beim testen können wir folglich auch nur auf die entsprechende bekannte information der schnittstelle zugreifen beispielsweise die signatur einer methode und optimalerweise natürlich die spezifikation einer tode methode und das ganze natürlich auch für ganze klassen was wir hingegen beim white box test zusätzlich betrachten ist die konkrete implementierung diese whitebox tests sind nur dann möglich wenn wir im quellcode kennen was in unserer situation als entwicklerinnen und entwickler natürlich üblicherweise der fall ist und in dem fall könnte tiefer gehen beim testen und können uns insbesondere unterschiedliche kontrollphase betrachten und dabei bedenken dass wir für jeden dieser kontrollwaage mindestens einen passenden test entwerfen also gibt es beispielsweise in einer methode eine fall unterscheidung in der wir einen if und einen l2 karben dann würden wir in dem fall bei einem white box test mindestens zwei tests entwerfen einem bei dem die parameter oder die der zustand des objektes dafür sorgen dass wir in den fcv hineingehen und ein zweiter teil der dann den l2 evaluiert um sicher zu gehen dass alle pfade tatsächlich auch korrekt arbeiten und mit einem test abgesichert sind und auf der anderen seite haben wir noch die unterscheidung zwischen dem positiv und dem negativ test der positiv test prüft dabei insbesondere das ab was wir als verhalten erwarten eine methode die die summe aus zwei zahlen berechnet für die würden wir dann zwei geeignete zahlen wählen und deren summe ausrechnen und dann gibt es mit dem negativ test noch die möglichkeit abzusichern was passiert denn wenn eine angabe ungültig ist wenn wir also beispielsweise zwei gleitkommazahlen addieren und eine dieser beiden gleitkommazahlen eine ungültige ist die zb durch die division durch 0 entstanden ist dann haben wir im jahr war ja die möglichkeit tatsächlich mit einem float wert eine solche ungültige zahl als model amber zu repräsentieren mit der können wir aber keine sinnvolle summen bildung mehr machen und insofern würden wir uns wünschen dass diese summen methode in einer geeigneten weise damit umgeht wir haben schon kennengelernt die möglichkeit mit einer liegl argument exception so etwas zu quittieren und ob das tatsächlich funktioniert auf eine solche liege argument exception geworfen wird wenn bei einer methode über methoden aufruf ungültige eingaben oder ein ungültiger zustand des umschließenden objektes vorliegen das können wir mit einem sowie positiv so genannten negativ test überprüfen also blackbox test nur von außen drauf gucken whitebox test die tatsächliche implementierung angucken positiv-test das erwartete verhalten wenn alles sich so verhält wie wir uns das ursprünglich bei dem entwurf der software vorgestellt haben und negativ wie gehen wir mit entsprechenden ausnahme situation um wir haben uns zu über das testen schon vorher unterhalten haben insbesondere festgestellt dass wir mit unit testing abgleichen erwartungswerte mit ist werten sollwerte mit ist werten und mussten uns aber da tatsächlich viele lösungen selber zusammen stricken das ganze wirkte etwas unaufgeräumt und wenig elegant und mit hilfe des unit frameworks können wir jetzt in der java welt eine ganz elegante trennung vornehmen zwischen unserem code dem eigentlichen arbeitsboot den wir testen wollen und dem entsprechenden test code auf der anderen seite und gleichzeitig tool unterstützung bekommen um tests auszuwerten und auch geeignet informationen darüber zu erhalten ob tests erfolgreich durchgelaufen sind oder fehlgeschlagen sind und das ganze basiert auf dem net framework das g unit framework ist nicht teil des java development kits wird aber dennoch in vielen fällen direkt mit installiert wenn wir beispielsweise unsere entwicklungs umgebung installieren ansonsten lässt es sich frei unter unit dot org herunterladen die aktuelle version ist 5 punkt irgendwas was ich eben ständig ändert da das framework kontinuierlich weiter getrieben wird wir müssen uns um die integration hier keine gedanken machen weil ich die abhängigkeit von jeju nicht direkt mit in der regel konfiguration des vorgabe kohleprojektes vorgesehen habe wenn man da mal nachgucken möchte gucken sie sich die datei bildpunkt cradle in ihrem wurzel verzeichnis des projektes an und dort finden sie die abhängigkeit von einer einigermaßen aktuellen g unit version für unsere zwecke vollkommen ausreichend und diese abhängigkeit wird entsprechend aufgelöst in dem moment wo sie erstmalig mit von great oder das projekt gebaut haben und sie müssen sich insofern nicht mehr damit beschäftigen die funktionalität von jay mit in ihr projekt einzubinden je nachdem welche funktionalität aus dem juke framework sie ganz konkret für ihre tests verwenden kann es aber notwendig sein dass sie einzelne klassen importieren müssen aber auch da unterstützt sie üblicherweise die entwicklungsumgebung so dass man sich da kaum selber drum kümmern muss nichtsdestotrotz wenn das manual notwendig ist wenn sie bisher noch nicht mit imports gearbeitet haben dann würde ich gerne ganz kurz darauf eingehen was das konkret bedeutet ein import ist eine bekanntmachung von funktionalität die sie in ihrer in ihrem projekt verwenden wollen insbesondere wenn es dort um klassen geht die sich nicht im gleichen package befinden in dem sich auch die klasse befindet in der sie damit arbeiten wollen im konkreten fall von der unit ist es zb so dass wir mit der test annotation arbeiten wenn wir gleich noch sehen was das ein bisschen konkreter bedeutet und die test annotation ist nun in einer klasse orc der unit dort jupiter dort ab dort test abgelegt und damit wir mit dieser annotation arbeiten können müssen wir in unserem projekt erstmal diese abhängigkeit auflösen indem wir in der klasse in der wir die test annotation verwenden wollen ein import statement verwenden das eben genau die abhängigkeit formuliert und sagt wenn ich hier mit test arbeite dann meine ich die klasse test die sich unter ort jupiter punkt abi befindet oder aber das als eine zweite variante man kann auch einen statischen import machen den statischen import haben wir schon mal kennen gelernt als wir über die marc hälker klasse gesprochen haben wir verwenden beispielsweise eine reihe von statischen methoden aus der sessions klasse und mit hilfe des statischen imports import static ort jupiter tapi dort sessions dort stern importieren wir jetzt alle statischen methoden aus dieser klasse s sessions und können dann etwa unser es hörte kurz was wir gleich einführen werden in unserem test klassen verwenden die arbeiten wir jetzt konkret mit dem unit framework zunächst einmal legen wir eine test klasse an dabei ist das übliche vorgehen dass wir für jede klasse die wir testen wollen eine eigene testklasse anlegen im beispiel der klasse bruch wenn wir die testen wollen würden wir also etwa eine klasse bruchtest anlegen das heißt auch von der namens konvention machen wir gleich klar dass sich diese klasse bruchtest auf die klasse bruch bezieht und dass es sich dabei um eine test klasse handelt genauso gehen wir vor mit den testmethoden wollen wir also beispielsweise eine methode addieren testen dann schreiben wir dafür eine passende test methode die wir nennen test addieren diese konvention ist nicht notwendig für unit das heißt also geld verlangt nicht dass wir uns an die konvention halten aber die hilft uns natürlich als leser um zu erkennen welche funktionalität denn in den entsprechenden testmethoden zu finden ist von joe hewitt eine anforderung ist allerdings dass die testmethoden zum einen immer den rückgabe typ weit also keinen rückgabe typ haben und dass sie entsprechend sichtbar sind indem wir sie als public deklarieren jetzt ist es häufig der wunsch dass wir die tests funktionalität trennen von der funktionalität die wir selber entwickelt haben dafür gibt es jetzt verschiedene ansätze in der braille in dem cradle system ist die konvention dass sich die test klassen in einem anderen unterverzeichnis befinden wenn sie sich ihr projekt noch mal angucken da gibt es dann immer source maine java und suns test java als zwei verzweiflungs strukturen für die verzeichnisse und all die packages die unter songs maine java liegen sind der eigentliche code und die passenden packages für die tests findet man dann unter source test java wie sieht jetzt eine solche testmethode in einer test klasse aus also wir nehmen hier als beispiel einmal an dass es eine klasse signal gibt die wir in irgendeiner weise testen wollen folglich nennen wir unsere testklasse testsignal und darin schreiben wir jetzt einzelne testmethoden nämlich eine testmethode mindestens eine testmethode für jede methode aus der original klasse die wir testen wollen wir führen die ein mit der annotation at test das heißt das ist die markierung dafür dass jetzt eine testmethode folgt und nur wenn wir diese annotation verwenden dann weiß der unit dass es die entsprechende testmethode mit in seine testfälle mit einbeziehen möchte und dann werden wir innerhalb der testmethode an mindestens einer stelle ein search statement formulieren müssen das ist dann der eigentliche test wo wir üblicherweise soll und ist miteinander abgleichen jetzt habe ich eben gesagt wir verwenden die add test annotation annotationen haben wir formal noch nicht eingeführt annotationen sind eine konstruktion um struktur in einen quellcode zu bringen und zwar auf eine sehr kompakte art und insbesondere können sie zur automatisierten erzeugung von programmcode verwendet werden wie man selber annotationen schreibt in java ist nicht test der programmieren veranstaltungen die wir hier in der einführung machen wir werden aber an der einen oder anderen stelle mit solchen annotationen arbeiten etwa otto bereit ist eine annotation die man im kontext von vererbung strukturen immer wieder verwendet oder eben jetzt eher test als markierung für das g unit framework um zu sagen jetzt kommt eine testmethode die bitte bei der test funktionalität mit in betracht gezogen werden soll diese annotationen sind nicht exklusiv für java sondern es gibt auch entsprechende umsetzung für sie ab oder visual basic dot net wir betrachten aber jetzt natürlich die java variante dieses at zeichen ist gefolgt vom namen der annotation der test ist jetzt die spezielle annotation die vom ta unit framework verwendet wird andere annotationen haben folglich einen anderen namen mit dieser annotation machen wir eine methode bekannt das heißt die tatsache dass wir eine methode in einer test klasse schreiben heißt noch nicht dass sie dann vom die unit framework mit betrachtet wird und für den test hinzugezogen wird sondern erst das verwenden von ed test für jede methode die eine testmethode sein soll sorgt dafür dass wir sie im jiu net framework verwenden und innerhalb der testmethode soll man jetzt üblicherweise einen abgleich machen zwischen soll und ist so wie wir es kennen gelernt haben und das wiederum passiert ja üblicherweise mit den sessions die wir jetzt gleich noch ein bisschen genauer betrachten werden was ist jetzt eine solche station auf deutsch zusicherung einer session ganz allgemein unabhängig von der unit unabhängig vom testen ist zunächst mal nur eine aussage eine behauptung über den zustand eines programms und üblicherweise sollen solche sessions solche zusicherungen natürlich war sein wir können damit zb anforderungen formulieren das ist etwas wie der zustand unseres programms sein soll das ist ein ergebnis das wir von unserem programm erwarten und mit solchen surgeons lassen sich insbesondere natürlich dann auch erwartungswerte formulieren resurgence wie gesagt müssen nicht in form von texten verwendet werden man kann es so sions auch einsetzen um zb innerhalb von regulären code an besonders entscheidenden stellen forderungen zu formulieren wo man sagt ich erwarte dass mein programm sich an dieser stelle auf eine bestimmte art verhält dass eine variable beispielsweise einen bestimmten wert hat so dass man in dem fall dass die session nicht war es beispielsweise ein kontrolliertes beenden des programms umsetzen kann im falle des unit tests verwenden wir die station jetzt um zu identifizieren ob ein testfall erfolgreich abgearbeitet wurde oder ob es dort vielleicht ein problem gab und insofern der entsprechende testfall fehlgeschlagen ist es gibt eine ganze reihe von surgeons die das gadget framework vorgibt wir werden in den meisten fällen das search tools verwenden das service erlaubt es uns jetzt einen sollwert mit einem ist wert abzugleichen und ich habe hier die variante mit entwerten verwendet aber tatsächlich gibt es hier überladene varianten für die unterschiedlichsten typen die wir dann mit einem surfkurs miteinander vergleichen können beispielsweise können wir das gleiche machen mit bullien werten und es gibt viele weitere sessions beispielsweise das trou dass dann keine werte mit mehr miteinander vergleicht sondern dass zunächst einmal erwartet dass der istwerte dort reingesteckt wird ein war heizwert ist und es wird ebenso unsere recherchen erwartet dass der entsprechende ausdruck war es so eine konstruktion können wir etwa verwenden wenn wir den ist und den sollwert schon selber vergleichen und dann natürlich erwarten dass da insgesamt war heraus kommt machen wir das ganze mal ein bisschen konkreter mit einem ganz konkreten beispiel wir betrachten hier die multiplikation methode aus der klasse bruch in dem fall soll der bruch multipliziert werden mit einem konstanten faktor das ergebnis soll ein neuer bruch sein wobei sowohl zähler als auch nenner die alten werte sind x dem angegebenen faktor und um nun eine testmethode für die multi methode zu schreiben legen wir zunächst mal eine entsprechende test klasse an das wäre hier bruchtest und in dieser test klasse definieren wir unter anderem eine testmethode für multi nennen wir test mut und wir markieren sie mit der annotation er test um dem unit framework zu sagen das ist eine methode die mit betrachtet werden soll bei der auswertung des tests falls und innerhalb des tests müssen wir jetzt also ein soll ist abgleich durchführen dazu konzern konstruieren wir ein oder mehrere beispiele sie erinnern sich an die verschiedenen rand fälle an die äquivalenz klassen die wir ja schon identifiziert haben die gelten hier natürlich ganz genau so ich habe hier mal ein beispiel bruch angelegt mit einem drittel den multipliziere ich jetzt mit zwei und in dem fall teste ich jetzt erstmal nur den zähler der zähler ist ja hier einst wenn ich den mit zwei multipliziere dann habe ich einen erwartungswert für den zähler von 2 und das formuliere ich jetzt mit einem artikel statement wo ich zunächst mal den erwartungswert angebe und dann den ist wert den ich aus meinem ergebnis auslese und bei der auswertung kann das tablet framework jetzt überprüfen ob hier tatsächlich zwei rauskommt wenn ja dann ist er dass es so schön erfolgreich und der test erfolgreich durch gelaufen wenn nein dann ist der test fehlgeschlagen und hier ist offensichtlich entweder ein fehler im test hoffentlich das nicht oder aber ein fehler im code und wir müssen uns entsprechend mit der korrektur des codes beschäftigen jetzt ist das framework sehr tief in den telegate verankert so dass wir da also eine große unterstützung haben zunächst mal habe ich schon gesagt dass die bibliothek über unser cradle konfiguration schon vorliegt das heißt also wir können direkt loslegen mit intelligenz zu arbeiten in unserem test klassen müssen wir natürlich die imports auflösen so wie ich das eben eingeführt habe also beispielsweise um die annotation test verwenden zu können brauchen wir hier den import of the witcher jupiter jupiter punkt ap punkt test und für unsere einzelnen search statements brauchen wir entsprechende statische imports auf die sessions klasse das übernimmt aber dann auch die unit entschuldigung dass intelligence system für uns liefert uns also entsprechende hilfs funktionalität so dass man vergleichsweise einfach die konfiguration umsetzen kann nachdem wir dann erfolgreich eine testklasse kompiliert haben können wir die einzelnen tests ausführen sie kennen ja schon das run symbol was wir mal dass sie auch immer verwenden um eine reguläre klasse insbesondere die methode auszuführen und ganz ähnliche symbole finden wir jetzt auch hier für das ausführen der junge tests das heißt auch die junge tests sind ausführbar und das insbesondere ohne eine methode das heißt das ausführen einer solchen test klasse die daran erkannt wird dass es mindestens eine test annotation gibt die sorgt dafür dass alle tests in der klasse ausgeführt werden wir können aber auch die einzelnen tests einzelnen ausführen und damit erstmal nur das ergebnis für einen einzelnen test abfragen wenn wir das ausführen dann bekommen wir das ergebnis des tests angezeigt im optimalen fall visualisiert hier durch solche grünen häkchen waren alle tests erfolgreich dann wissen wir dieser test hat gezeigt dass unser code den entsprechenden erwartungswert liefert oder aber auf der anderen seite wenn ein test fehlschlägt bekommen wir da eine information darüber dem beispiel gibt es nur einen test und der ist fehlgeschlagen wenn es aber mehrere tests innerhalb von dem ausgeführten code gibt dann könnte es hier natürlich auch mehrere tests seien von dem dann möglicherweise eine oder auch mehrere fehlschlagen und wenn ein test fehlgeschlagen ist dann können wir hier auf die entsprechende test aufruf klicken und bekommen dann hier in dem fenster angezeigt was denn da der fehler ist häufig ist es dann eine search statements wie in diesem beispiel hirschen fail terror erwartungswert war 23 zurück gelieferte wert war aber 24 das passt offensichtlich nicht zusammen und deswegen ist der test fehlgeschlagen noch einmal der hinweis darauf wie wir hier einen code und testrennen das ist üblicherweise ein gutes konzept die tests zu entkoppeln von der eigentlichen funktionalität und wir in den cradle projekten bekommen da die unterstützung durch die unterverzeichnisse source maine java und source test java unterhalb von diesen haupt ordnern werden wir dann die gleiche package struktur aufbauen für die original klassen und für die testklasse ich habe mal ein beispiel nehmen wir an wir haben in dem package vorlesungen vorlesung 15 maine punkt java code der getestet werden soll dann würde sich der zugehörige test unter source testjahr war nicht mein jahr war aber dann dem gleichen package vorlesungen vorlesung 15 test mein punkt java befinden und tatsächlich handelt es sich dabei dann de facto um das gleiche package sodass also diesem test mein klasse sich genauso verhält als würde sie sich in dem gleichen verzeichnis und damit dem gleichen pc package remane befinden obwohl wir durch die unterscheidung zwischen main und testsieger an zwei ganz unterschiedlichen orten auf der festplatte abgelegt haben [Musik]