Genau, ich weiß noch nicht,
ob es ein speziell gesunderten Termin gibt als Klausurvorbereitung.
Ja, genau. Nächste Woche sind wir in F zu 132.
Ja, gerne E-Mails schreiben. Man munkelt, ich antworte meistens
so nach fünf bis zehn Minuten, wenn ich nicht gerade schlafe.
Und genau, was für euch noch interessant ist,
was ihr euch vielleicht irgendwie abfotografieren könnt oder abschreiben könnt,
ist da, es gibt so eine schöne Webseite.
Auf der Webseite wird alles, was ich hier mache,
also halt Slides, PDFs, die ich baue oder irgendwelche Source-Code-Beispiele,
die wir hier zusammen machen, wird da halt alles hochgeladen.
Das heißt, ihr könnt euch voll und ganz darauf beschränken,
Sachen aufzuschreiben, die interessant sind.
Sie müssen jetzt nicht irgendwie alles abschreiben für eure Notizen.
Das kriegen sie euch nachher alles downloaden. Genau. Genau.
Und eventuell auf der Webseite kommen auch eventuell ab und zu mal Zusatzinhalte.
Das heißt, falls ich irgendwie eine schöne Frage bekomme,
auf die ich eine schöne Antwort mache,
dann kommt das natürlich aber auch gerne drauf,
dass das dann halt auch alle was von haben.
Ja, dann machen wir mal Erstmal so einen kleinen Check-up,
weil es ist ja schon ein bisschen länger her,
was in SR1 war.
Und das ist jetzt einfach mal so eine kleine Zusammenfassung,
was eigentlich ihr alles können solltet und hoffentlich auch könnt.
Jetzt mal so komplett unabhängig, erstmal von Java sind die ersten Sachen hier alle.
Das heißt, ihr habt ja hier Kontrollstrukturen kennengelernt, mit Fallunterscheidungen, unterschiedlichster Art.
Das ist elf mit Els If und Els oder halt Switch,
was ja eigentlich auch eine Fallunterscheidung,
also eine etwas andere Art von Fallunterscheidung ist,
Zählschleifen oder die etwas allgemeinere Variante davon ist ja die bedingte Schleif.
Dann haben wir ja so die Konzepte von objektobrientierten Programmieren gehabt,
wo wir dann so Interfaces kennengelernt haben,
was genau Interfaces beschreiben, irgendwie nur die methoden Köpfe.
Das heißt, ein Interface,
um es halt einfach mal auf Deutsch zu übersetzen,
ist eigentlich nichts anderes als die Beschreibung einer Schnittstelle.
Das heißt, ich beschreibe einfach nur,
wie soll eine Interaktion nachher mit ein Objekt oder einer Klasse,
die diese Schnittstelle implementiert,
ablaufen können
Also was darf ich für einen Ton aufrufen? Was brauchen
diese Methoden? Was geben sie mir zurück? Ja,
ohne jetzt werten zu sagen, was sie konkret machen sollen.
Also man beschreibt zwar schon, dass sie ein Ziel haben,
aber nicht, wie sie das Ziel erreichen.
Was ist denn eine Klasse? Oder vielleicht erst mal so
ganz einfach gesagt. Was wäre denn ein Bestandteil von der Klasse
? Methoden, genau. Okay, ich habe irgendwelche,
ich habe Methoden da drin, was habe ich dann vielleicht noch drin?
Den Namen, ja. Aber jetzt kommt ein ganz,
ganz, ganz wichtiger Teil,
was eigentlich der Grundgedanke hinter objektorientierten Programmieren ist
Also wenn ihr euch jetzt mal vorstellt, ihr habt die Klasse Buch.
Und das Buch kann ich aufschlagen, zuschlagen und weglegen.
Das sind so, die werden so die Operationen,
die ich darauf anwenden kann. Was hat so ein Buch noch?
Also die Klasse heißt Buch. Sollte vielleicht eine Seitenanzahl vielleicht.
Was ist das? Eigenschaften oder auch Zustand? Eine Klasse
definiert halt auch immer Zustandsfelder. Das ist ja das,
wenn wir uns jetzt Also wenn wir uns das jetzt mal anschauen,
wir haben ja immer hier unsere Klasse.
Und die besteht dann halt aus unseren Operationen.
Das ist dann so, was tut es?
Und dann haben wir ganz essentiell wichtig unseren Zustand.
Ja gut, da fällt mir jetzt kein guter Satz ein.
Aber genau. Und die Operationen sind ja meistens dafür da,
diesen Zustand in irgendeiner Art und Weise kontrolliert zu manipulieren.
Das ist ja dieses ganze, das ganze Konzept ist ja,
liegt ja daran, dass wir sagen wollen,
okay, wir haben, wir wollen irgendwas modellieren.
Also zum Beispiel halt jetzt ein Buch oder ein Konto.
Und der Zustand besteht ja eigentlich dann auch nur wieder aus
einer Zahl, zum Beispiel beim Konto.
Ich habe einen Kontostand. Und damit jetzt in normalen,
in nicht objektorientierten Programmiersprachen hat man dann natürlich das Problem,
ich kann ja einfach diese variablen Belegungen von dieser,
von dieser Zahl, von den Kontostanden,
kann ich ja einfach irgendwas drauf addieren,
irgendwas runter addieren
Und dann halt einfach nach Belieben machen, was ich will.
Und im Objekteorientierten ist es dann ja so,
dass ich sage, okay, ich habe hier ein Zustandsfeld
und dieses Zustandsfeld darfst du halt nur mit den Operationen,
die ich halt zur Verfügung stelle, manipulieren.
Da habe ich gedacht, da habe ich Bündeln, sagen wir,
okay, zu gewissen Daten, zu einem gewissen Zustand,
gehören immer gewisse Operationen und das Ganze zusammenbildet dann halt eine Klasse ab.
Wir haben ja dann natürlich auch noch Objekte,
was waren denn nochmal Objekte?
Und was war der Zusammenhang damit in Klassen?
Also wenn man so sagen möchte, dann sind es,
also Exemplare ist nochmal ein engerer Begriff von Objekten,
weil Objekte umfasst auch noch ein bisschen,
noch ein paar Sachen mehr.
Ich sag mal, für SE1 und SE2 reicht es auszusagen,
kann man sie eigentlich fast gleichsetzen.
Also es gibt noch so ein paar Spezialfälle irgendwann.
Wenn ich zwei Objekte von derselben Klasse habe,
das gibt es da irgendwie dann im Zusammenhang zwischen den Zuständen,
die beiden Objekte.
Also wenn ich mir jetzt vorstelle,
ich habe jetzt hier das Objektsbuch,
also irgendein Objekt vom Typ Buch
Und dann habe ich hier noch ein Objekt von Typ Buch.
Die haben ja jetzt beide irgendwie einen Zustand.
Das ist der Zustand gleich. Oder gibt es da
ein Verhältnis von Zustand zwischen den beiden?
Oder... Zustandsdelder, aber so schöne Dinge.
Genau, genau. Also, das heißt... Ja,
halt genau, sie können andere Belegungen haben, genau.
Also, das ist wahrscheinlich auch die deutlich bessere Variante.
Also, sie haben
immer dieselben Varie Zustandsfelder
Ja, das liegt halt einfach in der Natur.
Sie kamen ja, wurden ja von derselben Blaupause namens Klasse gebaut.
Aber wie jetzt deren Belegung ist, dass es halt,
sie kann dieselbe sein, sie kann in Teilen unter sich unterscheiden.
Wichtig, dass man sich das noch merkt.
Okay. Genau, ja, was verstehe,
also ich habe hier schon so den nächsten Punkt, ist Datenstrukturen.
Das ist so, glaube ich, das Lieblingsthema von sehr vielen.
Und da stehen da jetzt so Begriffe wie Rays
verkettete Listen,
Heshtavellen,
Erstmal so grob gesagt, was ist denn eigentlich eine Datenstruktur?
Also das Wichtige ist, dass man sich da halt jetzt so sagen muss,
es handelt sich da immer um etwas in irgendeiner Art und Weise geordnet ist.
Also es muss jetzt zum Beispiel nicht irgendwie alphabetisch geordnet sein oder nach einer Indexzahl geordnet sein,
aber Datenstrukturen sind in ihren Grundzügen halt immer im Bereich von,
ja,
ich liege da irgendwie auch schon so ein bisschen im Begriff mit drin,
dass sie halt eine Struktur aufweisen,
mit der sich irgendwie arbeiten lässt
Da gibt es dann halt,
wenn wir uns jetzt zum Beispiel Arays angucken,
was ist bei, wie sehen die aus?
Also wenn ich jetzt mir... Genau, okay.
Na? Das ist ja allerdings nichts anderes als sowas hier.
Ray, na und dann habe ich halt hier irgendwie so
den Index 0 und da steht jetzt zum Beispiel die Zahl 123.
Ja, ich glaube Grüße schreiben. Aber genau,
man hat halt immer,
bei Maray hat man immer
einen Index
Und dann eine Zuweisung für diesen Index. Wie kann ich
mir das irgendwie vorstellen? Wie liebt das denn beim Computer?
Wie wird das denn da abgelegt? So eine Ray einfach
. Ja, also wenn ich jetzt darauf zugreifen möchte.
Also wenn ich mir jetzt vorstelle, du sagst es hier mein.
Das ist jetzt hier irgendwie so mein Speicher. Das sind hier
einzelne Bytes. Es steht diese Zahl von diesem Index,
jetzt diese Null, steht die irgendwie im Speicher drin.
Genau, also beim Array ist es nämlich so,
dass diese Indexierung die es halt einfach dadurch,
die kommt dadurch zustande, wie die Daten abgelegt werden.
Und zwar ist es beim Array so, dass ich,
wenn ich jetzt zum Beispiel sage, ich möchte,
ne, also ich möchte jetzt zum Beispiel eine Ray haben,
ne, und das soll 100 Plätze haben.
Und wenn ich jetzt auch noch sage, okay,
das soll irgendwie vom Typ Intager sein, ne,
ein Inchanture ist, wie viel Bytes groß?
Also ein Inchiter ist dann halt viel, ist halt viel Bytes groß,
sagen wir jetzt einfach mal, ist ein Inchiter,
ist der Standard-Inchiter, ist ja eigentlich auch egal,
wie groß ein Inchiter ist, ne.
Also ich hab halt immer irgendeinen, ich hab halt da
einen Typ, Ja, und der hat eine gewisse Größe.
In diesem Fall ist es jetzt halt vier Bytes.
Und mit dieser Schreibweise sage ich jetzt den Computer, hey,
ich möchte jetzt bitte 400 Bytes-Speicher am Stück haben im Arbeitsspeicher.
Genau. Aber genau, man kriegt dann halt diese 400
Bytes. Und dieser Index kommt dann halt dadurch zustande,
dass ich sage, okay, ich möchte jetzt auf das nullte,
auf das nullte Element zugreifen.
Das heißt, ich habe dann ja eine Speicheradresse bekommen,
wo dieser Array anfängt. Also das gibt mir,
dieses Ray gibt mir dann halt irgendwie, nö,
also in Ja,
aber ist es halt
eine Referenz
Aber es ist halt auch nichts anderes als eine Speicheradresse. Und da sage ich jetzt,
okay, ich will nicht auf das nullte Element zugreifen will,
dann sind das die ersten vier Bytes. Und wenn ich als Index zum Beispiel zwei angebe,
dann ist das, was passiert ist, ich nehme dann meine,
also wenn ich jetzt hier das, meine Ray nehme,
und ich möchte jetzt irgendwie auf den Platz zwei zugreifen,
dann ist das, was passiert, dass ich sage,
okay, ich habe die Adresse von Midnorray,
und dann mache ich Plus, Ja,
dann hole ich mir hier die zwei.
Mal. Da muss ich mir hier vom Datentyp die Größe,
was dann ja in dem Fall vier Bytes ist.
Und dadurch rechne ich aus, wo ich im Speicher
gucken muss, wo diese Zahl dann ist.
Das heißt, beim Array ist es halt so,
dass dieser Index kommt halt einfach durch,
dadurch implizit,
an welcher Speicherstelle
da steht
Genau. Und genau. Und wenn wir uns das dann zum Beispiel jetzt angucken,
bei verketteten Listen, was war noch mal eine verkettete Liste?
Die habt ihr sogar, sollt ihr ja sogar anders selber implementieren.
Also wenn wir uns das jetzt nochmal so anschauen,
ich hab hier, ich hab hier einen Wächterknoten,
der war, ne, und wenn ich jetzt zum Beispiel sage,
okay, ich hab hier irgendwie einen Dahnkreis,
ich sag jetzt einfach mal,
diese verkettete Liste hat irgendwie,
speichert Kreise
Ja, das heißt, ich habe hier zwei Wächterknoten,
die definieren mir den Anfang und das Ende.
Sagen dann halt immer so, okay, was ist denn
das nächste Element? Fallen euch vielleicht jetzt irgendwie ad hoc
noch so aus dem Übungsbetrieb von letzten Semester eventuelle Probleme ein,
die so eine... Verkettete Liste mit sich bringt.
Außer, dass es vielleicht, wenn man es
das erste Mal implementiert, eventuell etwas schwieriger ist.
Ich muss ja irgendwie erstmal den letzten,
also ich muss ja irgendwie bis den letzten Knoten finden,
oder halt die Position,
wo ich einfügen will,
da muss ich ja
irgendwie erstmal hinkommen und den finden
Dort an meinen neuen Knoten einfügen und dann die ganzen Verbindungen verändern.
Okay, wer kann mir jetzt einen riesengroßen Vorteil von der Liste sagen?
Ich meine, was passiert denn zum Beispiel,
wenn ich mir jetzt beim Array angucke?
Ich habe da jetzt 100 Plätze reserviert. Was passiert denn,
wenn ich in das 101. Element da einfügen will?
Ich muss ein komplett neues Array bauen.
Ich muss die alten Daten in das neue Array rüberkopieren.
Genau, und dann hatten wir ja noch,
das muss ich überlegen, genau,
da hatten wir ja noch Hash-Tabellen
Ich weiß gar nicht mehr, sollte, ich glaube,
das war so in der letzten Woche oder in der vorletzten Woche
hat man das zumindest vor einem Jahr noch implementieren sollen.
Ist halt trotzdem nochmal gut, also Arays, verkehrtes Listen,
dann liebst auch noch sowas, das nennt sich Hesh-Tabelle.
Das kommt dann auf, wirkt man tatsächlich,
benutzt man es tatsächlich auch schon mal,
läuft das als Datenstruktur und so eine Hesh-Tabelle.
Dann gibt es noch einen Stack, was konnte ich mir
und dann, was kann ich mir unterm Stack vorstellen?
Okay, genau, also beim Stack ist es ja so,
ich backe einfach immer Sachen halt auf so einen Stapel,
das ist ja auch die deutsche Übersetzung davon
Ja, und ich kann halt immer das Oberste wieder runternehmen.
Ja, und kann dann halt immer wieder was draufpacken.
Ja, das findet sich tatsächlich, findet man das ja
sehr häufig in der Informatik, diese Datenstruktur wieder. Jetzt nicht unbedingt,
ich glaube jetzt, in irgendwelchem Business an,
also wenn man jetzt irgendwelche Java-Business-Anwendungen baut,
dann wird man vielleicht ein Stack jetzt nicht so häufig sehen,
aber es ist schon nicht schlecht, wenn man zumindest weiß,
dass es diese Datenstruktur gibt, um die sie funktioniert.
Okay, gut. Dann haben wir, genau,
da hattet ihr, glaube ich,
einen Kurzausflug in die UML gehabt
Also Klassendiagramm auf jeden Fall, da bin ich mir sehr sicher,
dass ihr das hattet, aber objektiert dann auch.
Was ist ein, so ganz kurz gesagt,
was zeigt dann eigentlich nur Objektdiagramm nochmal? Genau,
beim Objektdiagramm ist es halt so, ich mache halt ein,
sagen wir mal, Schnappschuss von dem Geflecht, von den Objekten.
Und das ist ja meistens so ein bisschen eher das Interessantere,
wie, wenn ich jetzt irgendwelche Objekte habe,
die halt vielleicht eine Referenz auf ein anderes Objekt haben,
wie sieht denn das jetzt eigentlich aus,
wenn ich das Programm laufen lassen würde
Dass man sich diese Gedanken halt auch einmal vorher macht,
bevor man das dann irgendwie versucht zu programmieren.
Oder in eurem Fall, ich glaube, in der Aufgabenstellung
war es eher so, dass man es hinterher machen soll.
Aber eigentlich ist es halt tatsächlich so nachher gedacht,
dass das dann nachher so Überlegungen sind,
die man sich vielleicht vorher macht.
Oder die man sich vielleicht deswegen macht,
weil man irgendwie einen Fehler gefunden hat.
Und jetzt versucht rauszufinden, warum passiert der Fehler überhaupt?
Genau, und was zeigt ein Klassendiagramm dann im Gegensatz zum Objektdiagramm?
Also ich habe erstmal, genau,
ich habe Klassen mit Zustandsfeldern und Methoden
Und was noch? Hat sich dann, da hatte ich dann irgendwie
so verschiedene Pfeilarten. Genau, ich zeige, genau,
genau, ich zeige dann auch nochmal irgendwelche, irgendwie halt Hierarchien auf,
wenn ich halt irgendwie Interfaces habe und dann klassen die diese Interfaces implementieren, ne? Ja,
also das ist ja auch irgendwie wichtig zu wissen, weil da,
aber so ein Klassendiagramm zeichne ich dann ja auch ein,
okay, wenn ich,
wenn jetzt zum Beispiel ein Zustandsfeld oder Exemplar fällt oder ich weiß gar nicht,
wie viele Namen das Ding noch hat, aber halt,
genau, Zustandsfeld, wenn das als Typ wenn das als Typ eine andere Klasse hat,
dann bilde ich das halt im Klassenserienraum auch ab.
Weil das ist ja eine wichtige Information, weil dadurch kann ich ja sagen,
okay, ich kann, diese Klasse kann nicht funktionieren,
solange nicht die andere Klasse schon da ist.
Also die andere Klasse muss zumindest so weit funktionieren,
dass ich irgendwie davon einen nächsten Plan erstellen kann und irgendwie damit schon interagieren kann.
Ansonsten, und dann hat man halt auch so einen leichten Up,
kann man dadurch sich aus so schönen Abhängigkeitsbaum machen,
um dann auch eine Idee zu haben, okay,
was muss wann programmiert werden eventuell oder wie
viele Leute können gleichzeitig dran programmieren
Das sind dann solche,
solche Entscheidungen, die man mit UML dann irgendwie hinkriegt.
Genau. Und dann haben wir noch eine etwas schwächere Bindung,
statt wird als Typ von Zustandsfeld benutzt.
Was gibt es da noch? In den Methoden als,
was hat so eine Methode? Parameter, genau.
Und was noch? Der Rückgabetyp. Weil ich muss ja
auch sagen, ich muss ja auch sagen,
was eigentlich eine Methode wieder zurückgibt.
Das heißt, wenn es so ist,
dass ich in der Klasse Methoden habe,
die halt entweder als Parameter oder als Rückgabetypen eine andere Klasse haben,
dann ist das eine schwächere Bindung.
Ja, also das Klassendiagramm ist eigentlich,
ist ja dazu gedacht, um sich einen Überblick zu verschaffen.
Und etwas, was man auch vielleicht immer so ein bisschen
im Höhekopf behalten muss, ist, ja,
da gehören Methoden rein in das Klassendiagramm,
aber nicht alle
Das heißt, im Klassendiagramm ist es dann halt eher so,
dass es ja eher so ein Werkzeug, womit ich mir Übersicht verschärfen soll.
Und wenn ich jetzt natürlich irgendwie eine Klasse habe mit 100 Methoden,
dann würde es jetzt der Übersicht, glaube ich,
eher schaden, wenn ich diese 100 Methoden in das Klassendiagramm reinschreibe.
Wobei man dann auch überlegen müsste, ob das sinnvoll ist,
eine Klasse mit 100 Methoden zu haben. Aber das heißt,
bei Klassendiagramm und Objektdiagramm ist es halt immer,
ist halt auch immer die Frage nach dem,
warum mache ich jetzt dieses Diagramm?
Also was soll das mir bringen
Weil theoretisch können sich ja beim Klassendiagramm
wirklich komplett bis nach ganz oben geben. Also irgendwann,
also je weiter ich höher gehe in der Hierarchie von den Klassen,
komme ich dann halt irgendwann bei Objekt an.
Es gibt so die Klasse Object in Java. Das ist
so alles. Also es kann alles sein oder auch nichts.
Ja, und das macht ja im Klassendiagramm jetzt keinen Sinn.
Immer bis da nach oben hin zu gesehen.
Man geht halt einfach, man schreibt halt so viel auf,
wie es halt gerade interessant ist für das,
was man sich anschaut.
Genau. Okay. Dann solltet ihr Software-Tests
gehabt haben
Okay. Also, ich nehme jetzt mal die ganze Magie einfach ganz schnell raus. Also,
das sagt eigentlich nichts anderes aus als bei Blackbox-Test,
sagt man immer davon, derjenige, der die Tests schreibt,
der kann sich, der hat keine Möglichkeit,
sich die Implementation anzuschauen von der Klasse, die er testet.
Das heißt, das Einzige,
was er halt sehen kann, ist das Interface,
also die Methoden, deren Rückgabetyp und deren Parameter und
dann halt wahrscheinlich noch am besten im besten Fallende Schnittstellen Dokumentation,
wo halt schreibt,
was die Methoden machen
Und dann schreibt er halt Tests, um halt zu schauen,
okay, in der Schnittstelle steht,
dass sich das Konto so verhalten soll,
dass man nicht niedriger gehen kann mit dem Saldo,
als zum Beispiel das Dispolimit erlaubt.
Und dann könnte man zum Beispiel einen Test schreiben,
wo man halt so lange Geld abhebt,
bis das halt der Fall ist, und schaut dann halt,
okay, verhält sich jetzt das Konto richtig.
Also erlaubt es dann zum Beispiel,
wenn das Limit überschritten werden würde mit der nächsten Abbehebung,
verweigert er dann zum Beispiel
die Abhebung
Das ist dann halt ein Blackbox-Test. Und das ist meistens auch die Testvariante,
die man im sogenannten Test-Driven-Development, also das,
was ihr ja in SE1 ein bisschen gegen Schluss dann kennenlernen solltet,
überall üblicherweise macht.
Da war es ja so, ihr schreibt erst ein Interface,
dann schreibt ihr die Tests und dann schreibt ihr die eigentliche Implementation von der Klasse.
Blackbox-Test ist dann sozusagen das,
was ihr dann eigentlich fast ganz SE2 bis zum Schluss
nur noch machen werdet irgendwann
Glaube ich nicht in der Übungswoche 1 noch nicht, aber spätestens,
wenn es dann nachher in die zweite Laborphase geht, da wo ja dann ja in Vierergruppen zusammenarbeiten sollt. Da wird es dann halt so sein,
dass man halt immer erst zuerst die, wenn man einigt,
sich auf ein Interface und im Idealfall ist es dann so,
dass dann zwei Leute schreiben dann die Tests im Perpo Ramming,
die anderen zwei Leute können dann schon mal die Klasse schreiben und das hat dann so den Vorteil,
wenn dann die Tests viel schlagen,
dann wurden entweder die Tests falsch geschrieben,
das kann man ja dann doch relativ schnell verifizieren,
weil dann Man hat sich ja auf ein Interface geeinigt.
Und wenn man dann verifiziert hat, okay,
die Tests enthalten jetzt keine logischen Fehler, dann weiß man,
okay, irgendwas stimmt in der Klasse nicht und kann dann durch die Tests auch relativ gut nachvollziehen,
wo etwas nicht stimmt.
Man kann sich das dann halt im Detail nochmal angucken.
Genau. Und ein Whitebox-Test ist halt das genaue Gegenteil.
Das heißt, ich weiß halt die komplette Implementation.
Ich weiß, wie es intern aufgebaut ist und schreibe dann
halt einen Test. Hat natürlich den Vorteil,
so einen Whitebox-Test, dass ich sehr viel genauer halt auf
eventuelle Implementationsdetails testen kann
Also wenn ich zum Beispiel weiß,
wie das If-Statement in der Methode halt geschrieben worden ist,
was da für eine Bedingung drinsteht,
dann kann ich ja viel gemeiner versuchen, irgendwie Eingabeparameter zu finden,
die das Statement dann irgendwie kaputt machen.
Und dann halt irgendwie nicht klasse in den Fehlerzustand bringt.
Aber hat natürlich auch den Nachteil, dass sich eventuell Fälle auslasse,
die vielleicht doch interessant gewesen wären, hätte ich gar nicht erst gewusst,
was das für eine Implementation ist.
Aber das ist so,
dass er das halt so ein bisschen im Hinterkopf hat,
Es gibt beides, aber in der Regel machen wir zumindest fast außernehmend,
außer fast nur Blackbox-Tests mit Positiv-Tests.
Weil also Negativ-Tests habe ich zumindest noch nie gesehen in den Übungen.
Also ja, weil Positiv-Test ist es ja so,
ich habe eine Erwartung. Also zum Beispiel,
ich habe die Methode Adiere und die hat zwei Parameter und meine Erwartung ist,
dass wenn ich da zwei und zwei reinpacke,
dass da vier rauskommt.
Das ist ein Positiv-Test
Das heißt, das schreibe ich dann auch im Test so rein.
Okay, ich gebe das als Parameter über. Das wird dann
halt auch der Funktion übergeben. Und dann wird geguckt,
ob das der Funktion, sag ich schon,
der Methode dann übergeben. Und dann wird halt geguckt,
ob das, was die Methode zurückgibt, auch dem entspricht,
was ich jetzt von Han selber auch nochmal gemacht habe.
Und beim Negativtest wäre es jetzt zum Beispiel so,
dass ich sage, okay,
wenn ich da jetzt als Parameter zwei und drei eingebe,
dann ist das auf keinen Fall vier
Das heißt, da mache ich, dann prüfe ich halt genau andersrum. Ich sage dann so,
ich möchte, ich möchte gucken, dass ich,
dass da halt irgendwie, ich teste halt,
ob da jetzt nicht falsche Werte rauskommen oder was halt auch interessant ist,
was man da, was dann vielleicht doch etwas praxisnäher ist,
dass man vielleicht guckt, dass wenn man irgendwie falsche Parameter übergibt,
wenn man jetzt zum Beispiel sagt, okay,
ich statt einer Zahl packe ich da jetzt irgendwie Nall rein,
wenn das irgendwie durch den Compiler noch durchgeht.
Und oder packe da halt einfach
irgendwelche Quatschwerte rein
Und erwarte jetzt davon, dass die Klasse in
irgendeiner Art und Weise in einen Fehlerzustand übergeht.
Das wird dann sehr auch gerne auch mit so einem
Negativtest gemacht