Grundlagen der Informatik I: T12 - Technische Universität Darmstadt

Technische Universität Darmstadt
Telecooperation/RBG
Grundlagen der Informatik I
Thema 12: Einführung in die objektorientierte
Programmierung mit Java
Prof. Dr. Max Mühlhäuser
Dr. Guido Rößling
Copyrighted material; for TUD student use only
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Inhaltsverzeichnis
• Objektorientierter Entwurf in aller Kürze; Klassen und
Objekte in Java
• Interpreter, Compiler, virtuelle Maschinen; JavaÜbersetzungs- und -Laufzeitumgebung
• Sichtbarkeit von Variablen in Java
• Packages
• Einführung in das Testen mit JUnit und Eclipse
Grundlagen der Informatik I: T12
2
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Objektorientierte Programmierung
• Eines der existierenden Programmierparadigmen
– Organisiert die zu modellierende Welt als eine Menge
kooperierender Objekte (OO-Systeme)
• Dabei gilt:
– Ein Objekt ist zuständig für einen spezifischen wohldefinierten
Teil der Berechnung
• Kapselt die Definition der dafür benötigten Daten und
Operationen, welche diese Daten verarbeiten
• Nimmt Dienste anderer ihm bekannter Objekte in Anspruch
– Jedes Objekt ist eine Instanz (Exemplar) einer Klasse
– Klassen sind in einer Vererbungshierarchie organisiert
• Bilden Begriffshierarchien der zu modellierenden Welt nach
Grundlagen der Informatik I: T12
3
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Objektorientierte Programmierung
• Beispiel: Modellierung der Immobilienfirma Nobel&Teuer
• Objekte repräsentieren Häuser, Mitarbeiter und Kunden
– Für jedes Haus sollen Informationen über den betreuenden
Mitarbeiter, den Besitzer… verwaltet werden
– Für jeden Kunden sind die zu verwaltenden Häuser, Name und
Telefonnummer… zu verwalten
– Mitarbeiter haben Namen, Telefonnummer, verwaltete Häuser
– …
• Verschiedene Typen von Häusern
– Ein- und Mehrfamilienhäuser
– Verschiedene Typen von Haus-Objekten werden in Erben der
Klasse Haus spezifiziert
Grundlagen der Informatik I: T12
4
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Objektorientierte Programmierung
Wichtig
Die Welt von
Nobel&Teuer
Müller
verwaltet
Schmidt
Besitzer
Reich
Grundlagen der Informatik I: T12
5
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Objektorientierte Programmierung
Objekt
Die Welt der
Immobilienfirmen
Ur-Objekt-Typ
Person
zuständig
für
2..10
Mitarbeiter Kunde
Manager
besitzt
* Haus
0..2
Einfamilienhaus
Verwalter verwaltet
Grundlagen der Informatik I: T12
Mehrfamilienhaus
Begriffe &
Kategorisierung
6
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
Objektorientierte Programmierung
Objekt
Die Welt der
Immobilienfirmen
Instanziierung
Person
zuständig
für
2..10
Mitarbeiter Kunde
Manager
©
besitzt
* Haus
0..2
Einfamilienhaus
Mehrfamilienhaus
Verwalter verwaltet
Grundlagen der Informatik I: T12
7
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassen
• Allgemein: Eine Klasse fasst Gemeinsamkeiten einer
Gruppe von Objekten (Instanzen) zusammen
– mit denselben Eigenschaften (Attributen)
– mit demselben Verhalten (Operationen)
Daten
(Variablen)
Konstruktionsvorschrift (Schablone)
für Objekte; beschreibt deren
Struktur und Dienste (Schnittstelle).
Grundlagen der Informatik I: T12
8
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassen in Java
<KlassenDefinition> =
class Klassen-Name [extends SuperKlassenName]
<KlassenDefinitionBlock>
<KlassenDefinitionsBlock> =
{ <MitgliedDefinition> ... <MitgliedDefinition> }
<MietgliedDefinition> = <InstanzvariablenDeklaration>
| <OperationsDefiniton>
| <KonstruktorDefinition>
• Der Definitionsblock einer Klasse besteht aus
– einer Menge von Variablendeklarationen
• Attribute, Instanzvariablen, Felder
– einer Menge von Operationsdefinitionen
– Konstruktordefinitionen
Grundlagen der Informatik I: T12
class Counter {
...
}
9
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Instanzvariablen (Felder)
• Instanzvariablen modellieren Eigenschaften von Objekten z.B.
aktueller Wert eines Zählers, aktueller Stand eines Kontos, …
– Haben einen Namen, einen Typ und einen Wert
• Der Name wird meistens klein geschrieben
• Der Wert ändert sich während der Ausführung
Zur Erinnerung: int ist ein
so genannter primitiver
class Counter {
Name
Typ in Java.
Stellt die Klasse der
natürlichen Zahlen
zwischen
-2.147.483.648 und
2.147.483.647 dar
Typ
}
(define (make-counter)
(local (
(define currentVal 10)
...
)
int currentVal;
...
class Counter {
int currentVal = 10;
...
}
Wert
Grundlagen der Informatik I: T12
10
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Konstruktor-Operationen
• Ein Konstruktor definiert mit Hilfe der Parameter eine
generische Initialisierungsvorschrift
• In Java sind Konstruktoren spezielle Operationen:
– haben den gleichen Namen wie die Klasse selbst
– haben keinen Rückgabewert
Formaler
Parameter des
Konstruktors
class Counter {
int currentVal;
...
Initialisierung der Felder mit
Counter(int initVal) {
den aktuellen Parametern eines
currentVal = initVal;
Konstruktor-Aufrufs
}
...
(define (make-counter initVal)
(local (
}
(define currentVal initVal)
...
)
Grundlagen der Informatik I: T12
11
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die Konstruktor-Operationen
• Eine Initialisierungsvorschrift wird einmal in einer
Klasse definiert und mehrfach benutzt
– Erzeugung mehrerer Zählerexemplare des gleichen
Typs mit unterschiedlich initialisierten
Instanzvariablen
...
Counter c1 = new Counter(3);
Counter c2 = new Counter(6);
...
Schlüsselwort für die Erzeugung
von Objektinstanzen
...
(define c1 (make-counter 3))
(define c2 (make-counter 6))
...
Grundlagen der Informatik I: T12
12
Die Java-Klasse Counter
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
class Counter {
int currentVal;
public Counter(int initVal) {
currentVal = initVal;
}
/**
* Effect: Increases the current value of counter by 1
*/
public int inc() {
currentVal = currentVal + 1;
return currentVal;
}
/**
* Effect: Decreases the current value of counter by 1
*/
public int dec() {
currentVal = currentVal - 1;
return currentVal;
}
/**
* @return the current value of the counter
*/
public int getCurrentVal() {
return currentVal;
}
Sichtbar
außerhalb der
Definition von
Counter
JavaDoc
Kommentar.
Hier aus
Platzmangel
verkürzt.
}
Grundlagen der Informatik I: T12
13
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassen in Scheme und Java
• Klassen werden in Scheme durch Konstruktor-Funktionen
(make-XXX) modelliert
– Spielen die Rolle der Java-Klassen und -Konstruktoren
– Geben Dispatcher-Funktionen zurück
• Der Dispatcher kombiniert und versteckt alle Dienstfunktionen
• In Java gibt es ein spezielles Konstrukt für Klassen
– Klassen sind nicht wirklich erstklassige Werte
– Klassen können mehrere Konstruktoren haben
– Dispatch-Mechanismus implizit in der Sprache
• Der Dispatcher ist Teil der Sprachsemantik und muss nicht
programmiert werden (später mehr)
Grundlagen der Informatik I: T12
14
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassenschnittstellen in Java
• Service Managers (dispatchers) in Scheme sind
Schnittstellenfunktionen, die Symbole auf Funktionen
verschiedener Typen abbilden
An address-book is an interface:
'add :: symbol number -> void
'search :: symbol -> number
• Die Schnittstelle einer Java-Klasse ergibt sich aus der Menge der
Operationen, die als public deklariert sind
– Nicht-öffentliche Operationen sind von außen unsichtbar
• Wir gehen fürs erste davon aus, dass sie nur von Methoden der
gleichen Klasse aufgerufen werden können
• Das stimmt nicht ganz; wir betrachten es später genauer
• Der Begriff einer Klassenschnittstelle als eine Funktion, die
Symbole auf Operationen mit einem bestimmten Vertrag abbildet,
bleibt jedoch gültig
Grundlagen der Informatik I: T12
15
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Einkapselung (Information Hiding)
class Counter {
int currentVal;
...
}
Felder und Operationen eines Objekts können versteckt werden.
Auf sie kann nur innerhalb der Implementierung der
(öffentlichen) Operationen der Klasse zugegriffen werden.
public static void main(String[] args) {
Counter c1 = new Counter(2);
int current = c1.currentVal;
current = c1.getCurrentVal(); // OK
}
Grundlagen der Informatik I: T12
16
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Geheimnisprinzip (Information Hiding)
• Generelle Design-Idee: Details eines Programm-Moduls
verstecken (z.B. Klasse oder Funktion)
• Mächtige Idee: reduziert die Komplexität von
Anwendungen
– Keine Notwendigkeit, die versteckten Details des Moduls zu
verstehen, um es zu verwenden.
– Reduziert die Kopplung zwischen Modulen
– Man kann die versteckte Implementierung ändern, ohne die
Klienten unwirksam zu machen.
– Modul-Schnittstelle als Vertrag.
• Wir kennen diese Design-Idee schon
– Datenabstraktion: Repräsentation des
Datentyps verstecken
– Make-Funktionen verstecken lokale Objektdefinitionen
Grundlagen der Informatik I: T12
17
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Kapselung
• Idee: Kombination von Elementen, um größere
Einheiten zu erzeugen und dabei die Details der
Komposition zu verstecken.
• Kapselung ist ein Mechanismus, um Informationen zu
verstecken.
• Der Begriff wird manchmal in einem gröberen Sinn
verwendet.
– Als Synonym für information hiding
• Der Begriff wird manchmal in einem spezifischeren
Sinn verwendet
– “Daten und Operationen zusammen”
Grundlagen der Informatik I: T12
18
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassen als zweifache Abstraktion…
…beschreiben nur
solche Felder und
Dienste von realen
Objekten, die
relevant für die zu
entwickelnde
Software sind.
In der Definition einer Klasse werden unwichtige
Unterschiede zwischen allen möglichen Elementen
(Objekten) einer Klasse außer Acht gelassen
Beispiel: Unterschiede in den aktuellen Werten der Zähler
Grundlagen der Informatik I: T12
19
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Klassen und Objekte
• Klassen in Java sind statische Beschreibungen ("auf
Papier" bzw. "in der Datei")
 Pläne (engl. blueprints)
• Objekte sind Laufzeitelemente eines Programms 
Werte
– dynamisch (sind zur Programmausführungszeit im
Hauptspeicher des Rechners)
– Es kann mehrere Objekte einer Klasse geben, jedes mit eigener
Identität und eigenem Zustand
– Objekte sind über einen Namen ansprechbar
• Jedes Objekt gehört einer Klasse an und kennt seine
Klasse
– Die Klasse kennt ihre Objekte in der Regel nicht
Grundlagen der Informatik I: T12
20
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Charakteristika eines Objekts
Grundlagen der Informatik I: T12
21
Berechnungen durchführen
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
• Jede Berechnung in einem OO-Programm geschieht als Folge des
Aufrufs einer Operation auf einem vorher erzeugten Objekt
• Beachten Sie die „Punkt-Notation“ für den Aufruf von Methoden
public class CounterConsumer {
Counter c1 = new Counter(3);
Counter c2 = new Counter(6);
(begin
(inc
(inc
(dec
public void doSomethingWithCounters() {
c1.inc();
c1.inc();
c1)
c1.dec();
c1)
System.out.println(c1.getCurrentVal());
c1))
(begin
(inc c2)
(dec c2))
}
}
(getCurrentVal c1)
c2.inc();
c2.dec();
System.out.println(c2.getCurrentVal());
(getCurrentVal c2)
Grundlagen der Informatik I: T12
22
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Berechnungen durchführen
• Die Aufgabe wird in Dienstanweisungen zerlegt
– Formuliert als Nachrichten (Operationsaufruf) an Objekte
• Jede Nachricht enthält:
– Name des Empfängerobjektes: c1 im Beispiel
– Namen des Dienstes (der Operation), der (die) vom Empfänger
ausgeführt werden soll
• inc(), dec(), ...
• Die Operation muss in der Schnittstelle des Empfängers enthalten
sein
• Es wird nur eine Nachricht mit einer Dienstanweisung
auf einmal geschickt
• Wenn mehrere Objekte vorhanden sind, können sie
Botschaften aneinander senden
– Teilaufgaben an bekannte Objekte delegieren
Grundlagen der Informatik I: T12
23
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Zur Erinnerung: Wie alles anfängt…
• Die „ausgezeichnete“ Methode namens main wird
aufgerufen, wenn ein Java-Programm ausgeführt wird…
public class CounterTest {
// ...
public static void main(String[] args) {
CounterConsumer cc = new CounterConsumer();
cc.doSomethingWithCounters();
}
// ...
}
CounterTest.java
JavaCompiler
JavaBytecodeInterpreter
javac CounterTest.java
java
CounterTest
Grundlagen der Informatik I: T12
24
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Inhaltsverzeichnis
• Objektorientierter Entwurf in aller Kürze; Klassen und
Objekte in Java
• Interpreter, Compiler, virtuelle Maschinen; JavaÜbersetzungs- und -Laufzeitumgebung
• Sichtbarkeit von Variablen in Java
• Packages
• Einführung in das Testen mit JUnit und Eclipse
Grundlagen der Informatik I: T12
25
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Interpreter
•
Ein Interpreter ist ein Programm, das ein Programm einer
bestimmten Programmiersprache direkt ausführt.
•
Arbeitsweise eines Interpreters (inpExpr ist der
aktueller Ausdruck des auszuführenden Programms)
1. Syntaktische Analyse von inpExpr
2. Überführung von inpExpr in eine Befehlsfolge der
Maschinensprache, oder der Sprache, in der das
Interpreterprogramm selbst geschrieben ist (outExpr)
3. Ausführung von outExpr
4. Wiederholung der Schritte (1) bis (3) für die nächste
Anweisung.
Grundlagen der Informatik I: T12
26
Definition eines Übersetzers
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Programm in
der Sprache B
Programm in
der Sprache A
Übersetzer
Quellprogramm P1
A  Quellsprache
B  Zielsprache
Zielprogramm P2
Ausführung
• Ein Übersetzer (Compiler) ist ein Programm, das
Programme aus einer Programmiersprache A in eine
Programmiersprache B übersetzt
• Semantische Korrektheit
– Jedem Quellprogramm P1 in A wird genau ein Zielprogramm P2
in B zugeordnet.
– Das dem Quellprogramm P1 zugeordnete Zielprogramm P2 muss
die gleiche Bedeutung (Semantik) wie P1 besitzen.
Grundlagen der Informatik I: T12
27
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Übersetzer (Compiler)
Konteradmiral Grace Murray Hopper (1906–1992)
Nach eigener Aussage
hat sie den Compiler
aus Faulheit erfunden,
und weil sie hoffte,
dass "Programmierer
wieder Mathematiker
werden" könnten.
Grundlagen der Informatik I: T12
28
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Übersetzungsphasen
Lexikalische Analyse
Quellprogramm wird in eine Folge
von Worten zerlegt
Syntaktische Analyse
Testet, ob das Quellprogramm den
Syntaxregeln der Quellsprache entspricht.
Strukturiert Worte in gültige Sätze.
Semantische Analyse
Testet, ob alle im Quellprogramm
benutzten Namen deklariert wurden und
ihrem Typ entsprechend verwendet
werden, usw.
Code-Generierung
Zielprogramm wird erzeugt
Grundlagen der Informatik I: T12
29
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
Traditionelle Übersetzung
©
Quelltext in Sprache A
Compiler für
Sprache A und
Prozessor Y
Compiler für
Sprache A und
Prozessor X
Ausführbares Programm
(Binärcode) für Prozessor X
Compiler für
Sprache A und
Prozessor Z
Ausführbares Programm
(Binärcode) für Prozessor Z
Ausführbares Programm
(Binärcode) für Prozessor Y
N Sprachen
Pascal
N*M Compiler
M Plattformen
Sun
Smalltalk
PC
Java
Prolog
Apple
C++
Grundlagen der Informatik I: T12
30
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Vor- und Nachteile traditioneller Übersetzung
• Vorteil: Optimale Ausnutzung der jeweiligen
Prozessor-Eigenschaften
– Hohe Abarbeitungsgeschwindigkeit der übersetzten
Programme
• Nachteil: Plattformabhängigkeit
– Ein Programm, das in einer höheren Programmiersprache
geschrieben ist, kann theoretisch nach der Anwendung der
entsprechenden Übersetzer auf jeder Maschine laufen...
„The difference between theory and practice is
that in theory, there is no difference between
theory and practice, but in practice there is.“
Grundlagen der Informatik I: T12
31
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Vor- und Nachteile traditioneller Übersetzung
• Das übersetzte Programm läuft nur auf dem jeweiligen
Prozessortyp
– Für jeden Prozessortyp und jedes Betriebssystem muss
das Programm mit einem anderen Compiler neu
übersetzt werden.
• Windows auf PC != Linux auf PC
• Plattformabhängigkeit: es gibt unterschiedliche Dialekte
einer Sprache
– Bestimmte Eigenschaften der Maschine beeinträchtigen
den Compiler-Entwurf
• Z.B. Größe der Register oder Speicherzellen beeinträchtigt die
maximale Länge der Zahlen, die manipuliert werden können.
– Daher gibt es oft verschiedene Dialekte einer Programmiersprache
Grundlagen der Informatik I: T12
32
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Virtuelle Maschinen (VM)
• Eine virtuelle Maschine ist ein Programm, das die Arbeit
eines Prozessors in Software simuliert
• Programme einer höheren Sprache werden in eine
Assembler-ähnliche Zwischensprache übersetzt
– Der simulierte Hardware-Prozessor nutzt diese
Zwischensprache und besitzt einige Software-Register
– Die Anweisungen der Zwischensprache nennt man
auch Byte-Code
• Die Zwischensprache wird von der Virtuellen Maschine
interpretiert
• Eine virtuelle Maschine versteckt die spezifischen
Eigenschaften eines konkreten Prozessors  eine neue
Abstraktionsschicht auf der Hardware-Ebene!
Grundlagen der Informatik I: T12
33
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Vor- und Nachteile von Interpretern
• Vorteil: es lassen sich relativ schnell lauffähige
Programmversionen erstellen  Prototyping
– Schnelle Änderbarkeit: geänderte Anweisungen /
Deklarationen des Quellprogramms sind sofort ausführbar
• Neuübersetzung nicht notwendig
• Nachteil: Längere Ausführungszeit
– Werden Anweisungen des Quellprogramms k-mal verwendet
(z.B. bei Schleifen), werden sie k-mal analysiert und
überführt
– Bei Zugriffen auf Variablen müssen die zugeordneten
Adressen immer wieder bestimmt werden.
Grundlagen der Informatik I: T12
34
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
N Sprachen
Pascal
Virtuelle Maschinen (VM)
N + M Compiler
M Plattformen
Sun
Smalltalk
Virtuelle
Maschine
PC
Java
Prolog
Apple
C++
Eine VM verdeckt die speziellen Eigenschaften des jeweiligen
Prozessortyps  Abstraktionsschicht!
Grundlagen der Informatik I: T12
35
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Vor- und Nachteile der VM-Technologie
• Vorteile: Übersetzte Programme einer Sprache laufen auf allen
Prozessortypen, für die es einen Byte-Code Interpreter gibt
– Es wird nur ein Compiler benötigt
 Die Sprache wird plattformunabhängig
– Natürlich braucht man eine VM pro Prozessortyp!
• Nachteil: Byte-Code Programme sind langsamer als
Maschinenprogramme
– just-in-time-compiler (JIT): Übersetzen den Byte-Code in
ein Objekt-Programm für einen speziellen Prozessortyp
• sobald es geladen wird, oder nach der ersten Ausführung
Grundlagen der Informatik I: T12
36
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Java-Übersetzungs- und -Laufzeitumgebung
Übersetzungsumgebung
Laufzeitumgebung
Class Loader
Bytecode
Verifier
Java Source
(.java)
Java Compiler
(javac)
Java
Bytecode aus
Dateisystem
oder Netz
Java Klassenbibliothek
Java VM
Java
Just-in-time
Interpreter
Compiler
Java Laufzeitumgebung
Java Bytecode
(.class)
Betriebssystem
Hardware
Grundlagen der Informatik I: T12
37
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Struktur eines Java-Programms
• Ein Java-Programm kann aus beliebig vielen Klassen
bestehen, von denen mindestens eine die mainOperation besitzen muss (Hauptprogrammklasse).
• Aufgaben von main:
– Objekterzeugung  der Aufbau einer anfangs minimalen Welt
– Aufruf der ersten Operation
– Sollte in der Regel keinen weitergehenden Kontrollfluss des
Java-Programms enthalten
• Der Kontrollfluss wird innerhalb der Objektoperationen realisiert
– Nicht vergessen! Berechnung als Kooperation von vielen
Objekten, wobei jedes Objekt nur eine kleine Teilaufgabe
erledigt!
• main wird mit Hilfe des Java-Interpreters gestartet und
ausgeführt
Grundlagen der Informatik I: T12
38
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Java-Laufzeitumgebung
• Java Interpreter: Programm zur Ausführung des JavaBytecodes auf dem konkreten Rechner
• Just-In-Time-Compiler (JIT-Compiler)
– Eine Klasse kann (optimal) nach dem Laden direkt in MaschinenCode der jeweiligen Maschine übersetzt werden
– Falls die vorliegende Java-Installation keinen JIT-Compiler
besitzt, wird der Bytecode vom Java-Interpreter direkt
ausgeführt
• Runtime-System: Stellt einem Java-Programm wichtige
Ressourcen zur Verfügung
• Bytecode Verifier: überprüft, ob die geladenen Bytecodes der
JVM-Spezifikation entsprechen
– Klassen können über das Netz oder aus dem lokalen
Dateisystem zur Laufzeit einer Java-Anwendung in das
Laufzeitsystem nachgeladen werden
– Ein Teil der Sicherheitsmaßnahmen wird durch den
Bytecode Verifier realisiert
Grundlagen der Informatik I: T12
39
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Java-Übersetzung (Wiederholung)
• Java-Compiler
– Eingabe: Java-Quelltextdatei, Datei.java, die eine oder
mehrere Klassendefinitionen enthält
• Eine derartige Datei nennt man eine Übersetzungseinheit
– Ausgabe: pro Klasse Bsp wird genau eine Datei Bsp.class
erzeugt, die das Bytecode-Format der Klasse enthält
class Bsp1 {...}
class Bsp2 {...}
class Datei {...}
Java Compiler
Datei.java
Grundlagen der Informatik I: T12
Bsp1.class
Bsp2.class
Datei.class
40
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Inhaltsverzeichnis
• Objektorientierter Entwurf in aller Kürze; Klassen und
Objekte in Java
• Interpreter, Compiler, virtuelle Maschinen; JavaÜbersetzungs- und –Laufzeitumgebung
• Sichtbarkeit von Variablen in Java
• Packages
• Einführung in das Testen mit JUnit und Eclipse
Grundlagen der Informatik I: T12
41
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Sichtbarkeit von Variablen in Java
•
Der gleiche Variablenname kann mehrfach verwendet werden,
z.B. Instanzvariable, Parameter, lokale Variable einer Methode
oder eines Blocks.
•
Wie in Scheme, lexical scoping: innere Deklarationen haben
immer Vorrang vor äußeren Deklarationen.
– Auf äußere Deklarationen kann man nicht mehr direkt
zugreifen
– Mit this.<attribute-name> kann man auf Instanzvariablen
zugreifen
– Lokale Variablen und Parameter können nicht re-deklariert
werden
•
Redeklaration beeinflusst die Existenz der äußeren Variablen nicht
– Fehlende Sichtbarkeit bedeutet kein fehlendes Vorhandensein!
– Außerhalb des Deklarationsblocks ist die äußere Variable
wieder sichtbar
Grundlagen der Informatik I: T12
42
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Sichtbarkeit von Variablen in Java Klassen
Lexical scoping a la Java
class Example {
Klassen-Scope
int i;
char c;
void g(int n) {
Scope von Methode g
int i, j;
Scope der for-Schleife
for (char c... ) {
int k;
… i … k … c … n … this.i …
}
… c …
}
}
Grundlagen der Informatik I: T12
43
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Inhaltsverzeichnis
• Objektorientierter Entwurf in aller Kürze; Klassen und
Objekte in Java
• Interpreter, Compiler, virtuelle Maschinen; JavaÜbersetzungs- und –Laufzeitumgebung
• Sichtbarkeit von Variablen in Java
• Packages
• Einführung in das Testen mit JUnit und Eclipse
Grundlagen der Informatik I: T12
44
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Packages
• Packages bündeln Klassen, die im Hinblick auf
Zuständigkeit zusammen gehören.
• Hilft Namenskonflikte zu vermeiden.
– Klassennamen müssen eindeutig sein (aber nur in einem
Package)
 Mehrere Klassen können den gleichen (nicht public) Namen
haben, z.B. List
• Versteckt Klassen, die nur interne Zwecke haben und
die nach außen nicht sichtbar sein sollen.
Grundlagen der Informatik I: T12
45
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Package Hierarchien
• Packages sind hierarchisch organisiert
 Ein Package kann andere Packages enthalten, die
wieder mehr Packages enthalten, usw.
• Punkt-Notation für Package Namen
package.subpackage.subsubpackage.Class
• Der Kopf einer Java Datei gibt an, mit welchem
Package die folgenden Klassen verbunden sind.
Grundlagen der Informatik I: T12
46
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Namenskonventionen für Packages
• Der Package Name spiegelt den Internet Domain
Namen des Herstellers in umgekehrter Reihenfolge
• Schräg- und Bindestriche sind nicht erlaubt:
– SUN URL: sun.com
 SUN class: com.sun.p1.p2.Class
– TUD URL: informatik.tu-darmstadt.de
 TUD class:
de.tu_darmstadt.informatik.p1.Class
Die Konvention erlaubt die Definition weltweit
eindeutiger Klassennamen.
Grundlagen der Informatik I: T12
47
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Deklaration von Packages
• Der gleiche Package Name kann in mehreren Dateien
verwendet werden
– Ein Package kann über mehrere Dateien verteilt
sein
 schnellere (Re-)Compilierung
 Unterstützt die Arbeitsteilung in größeren
Projekten
• Der volle Name einer Klasse enthält immer den
Package Namen (packagename.ClassName)
• Shortcut Notation mit nur dem Klassennamen ist nur
innerhalb des selben Packages möglich oder wenn das
Package bzw. die Klasse importiert wurde.
Grundlagen der Informatik I: T12
48
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Struktur einer Java Datei
<Source-File> ::= <Package-Declaration>
<Import-Declarations>
<Type-Definitions>
<Package-Declaration> ::= package <Package-name> ; | ε
<Package-Name> ::= <Identifier> {. <Package-Name>}
• Nur Kommentare oder leere Zeilen dürfen vor der
Package Deklaration stehen.
• Nur ein Package Name pro Datei
• Ohne eine Package-Deklaration werden die enthaltenen
Klassen einem anonymen Standard Package hinzugefügt.
Grundlagen der Informatik I: T12
49
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Package Import
<Import-Declaration> ::= import <Package-Name> .
(<Class-Name> | *) ;
• Eine Klassendefinition nach einer import-Anweisung
kann auf die importierte Klasse zugreifen, ohne den
vollständigen Namen zu nennen.
• Wenn "*" (wild card) benutzt wird, kann man auf alle
Klassen des Packages zugreifen.
• Falls nur Klassenmethoden (static) importiert werden
sollen, langt auch folgende Notation:
import static <Package-Name>.<Class-Name>.<Methode>;
Grundlagen der Informatik I: T12
50
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Verwendung von Packages
• Verwendung der vollständigen Kennzeichnung (full
qualification)
java.util.Random numberGenerator
= new java.util.Random();
• Verwendung von import
import java.util.Random;
...
Random numberGenerator = new Random();
Grundlagen der Informatik I: T12
51
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Package Import
• Das Importieren von Klassen mit dem selben Namen
erzeugt einen Namenskonflikt
import java.awt.*;
// hat Klasse List
import java.util.*; // hat Klasse List
...
java.util.List list; // verwende den
// Package-Namen, um
// eine auszuwaehlen
• Zwei Packages werden automatisch importiert
– Das aktuelle Package
– Das vordefinierte Package java.lang, das grundlegende
Klassen wie Object, String, usw. enthält.
Grundlagen der Informatik I: T12
52
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Package Import
Die Java API enthält eine große Zahl vordefinierter
Packages (alle Teil vom JDK), unter anderem
– java.applet
Applet-Unterstützung
– java.io
Input/Output, Dateien
– java.net
Netzwerk-Unterstützung
– java.util
Utility Typen, z.B. Containertypen
– java.util.zip Unterstützung für .zip Archive
– …
Grundlagen der Informatik I: T12
53
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Namensgebung für Packages
Package-Namen und Verzeichnisstrukturen
Die Stellen der Dateien, die ein Package definieren,
spiegelt die hierarchische Struktur des Packages
wieder.
• Punkte müssen ersetzt werden durch:
– UNIX  Slash " / "
– Windows  Backslash " \ "
Beispiel:
– Name des Packages:
kilian.hobby.raytracer
– zugehörige UNIX Verzeichnis-Struktur:
kilian/hobby/raytracer
Grundlagen der Informatik I: T12
54
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Packages einbinden
Packages und "CLASSPATH"
• Ein Package Name wird als relativer Pfad verstanden
• Die Umgebungsvariable CLASSPATH enthält alle
Verzeichnisse, die nach Klassen und Packages
durchsucht werden.
• Darüber hinaus kann ein CLASSPATH auch auf ZIP und
JAR-Archive verweisen, die Klassen enthalten
• UNIX Beispiel
CLASSPATH=.:/home/joe/classes:/usr/classes.zip
Aktuelles
Verzeichnis
Weitere
Verzeichnisse
Grundlagen der Informatik I: T12
55
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Packages einbinden
Packages und "CLASSPATH"
• Die Verzeichnisse aus CLASSPATH sind die
Startpunkte für die relativen Pfade zu den Packages
• Die Suchreihenfolge ist von links nach rechts
• Es ist möglich, dass ein Package Name mehrere
Verzeichnisse bezeichnet.
 Keine gute Idee, da die Auswahl der Packages dann
von der Reihenfolge des Auftretens dieser
Verzeichnisse im CLASSPATH abhängt.
Grundlagen der Informatik I: T12
56
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Inhaltsverzeichnis
• Objektorientierter Entwurf in aller Kürze; Klassen und
Objekte in Java
• Interpreter, Compiler, virtuelle Maschinen; JavaÜbersetzungs- und –Laufzeitumgebung
• Sichtbarkeit von Variablen in Java
• Packages
• Einführung in das Testen mit JUnit und Eclipse
Grundlagen der Informatik I: T12
57
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Testen mit JUnit und Eclipse
Test-first programming  Unsere Entwurfsrezepte verlangen, dass
wir Tests schreiben, bevor wir mit dem Programmieren anfangen
JUnit ist ein Programm (framework), das das Schreiben und
Ausführen von Tests teilweise automatisiert
• JUnit ist bereits in Eclipse integriert
Der Ärmste... wir hätten ihm bei der Einstellung sagen sollen, dass
er zuerst testen und dann programmieren soll.
Grundlagen der Informatik I: T12
58
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Motivation für JUnit
• Analog zu unseren Testfällen in Scheme wollen wir auch in Java
unsere Programme testen können
• Wir schreiben dazu ein Testprogramm, welches die Operationen mit
Beispiel-Daten benutzt und die Ergebnisse auswertet
– Testprogramm wird zur Entwicklungszeit zum eigentlichen Programm
parallel weiterentwickelt und ausgeführt
– Immer dann, wenn wir wissen möchten, ob gewisse Testfälle noch
laufen
Wir verwenden ein Framework, hier JUnit
- für automatisierte Unit-Tests
Grundlagen der Informatik I: T12
59
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Annotationen
• Bevor wir uns JUnit widmen, möchten wir einen Blick
auf Annotationen werfen
– Die neueste Fassung von JUnit nutzt Annotationen
• Annotationen liefern Metadaten über den Programmcode
• Java 1.5+ definiert 7 Annotationen
– Möglichkeit zur Ergänzung durch nutzerdefinierte Annotationen
– 3 „echte“ Annotationen
– 4 Meta-Annotationen
• Annotationen werden mit einem @-Symbol im
Programm-Code markiert
– Zum Beispiel: @SuppressWarnings
• Annotationen verweisen auf eines der folgenden
Elemente
– Element = Code-Zeile, Methode, …
Grundlagen der Informatik I: T12
60
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Echte Annotationen
• @Override
– Zeigt an, wenn eine Methode aus der Basisklasse durch eine
andere Methode überschrieben wird.
– Kann verwendet werden, um auf Tipfehler und Fehler in den
Signaturen von Methoden zu testen.
• @Deprecated
– Verursacht eine Compiler-Warnung, wenn das folgende Element
verwendet wird
• @SuppressWarnings
– Unterdrückt Compiler-Warnungen für das folgende Element
Grundlagen der Informatik I: T12
61
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Meta-Annotationen
• @Target(args)
– Wo können Annotationen verwendet werden?
– Zusätzliche Argumente: CONSTRUCTOR, FIELD,
LOCAL_VARIABLE, METHOD, PACKAGE, PARAMETER, TYPE
• @Retention(args)
– Wie lange sollen Annotationen behalten werden?
• SOURCE = Vom Compiler verworfen
• CLASS = Verfügbar in Klassen-Datei, zur Laufzeit verworfen
• RUNTIME = Von Virtual Machine für die Laufzeit-Nutzung
beibehalten
• @Documented
– Schließt Annotation in JavaDoc ein
• @Inherited
– Erlaubt es Unterklassen, Annotation zu erben
Grundlagen der Informatik I: T12
62
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Annotationen: Beispiel
• Die Annotationen @Target und @Retention können
genutzt werden, um neue Annotationen zu definieren
• Neue Annotationen werden wie Interfaces definiert mit
dem Schlüsselwort @interface (mit @-Präfix)
• Beispiel:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface UseCase {
public int id();
public String description()
default "no description";
}
Grundlagen der Informatik I: T12
63
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Annotationen: Beispiel
• Wie können vorausgegangene Annotationen genutzt
werden, um “Use Cases” zu generieren?
public class PasswordUtils {
@UseCase(id = 47, description =
"Password must have one number")
public boolean validatePassword() {
// ...
}
@UseCase(id = 48)
public String encryptPassword() {
// ...
}
}
Grundlagen der Informatik I: T12
64
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Annotationen und JUnit
• Die aktuelle Version von JUnit basiert auf
Annotationen
• Testfälle werden mit der Annotation @Test
markiert
• Frühere Versionen brauchten spezielle
Konventionen bei den Namen der Test-Klassen
– In JUnit 4 ist das nicht mehr notwendig
• JUnit-Demo, aber im Vorfeld noch ein paar
Worte zum Testen
Grundlagen der Informatik I: T12
65
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Teststadien
Entwicklungsphasen mit zugehörigen Tests
Kundenwünsche
Abnahmetest
Systemtest
Anforderungen
Entwurf
Integrationstest
Code
Unittests
A
X
B
Y
A wird vor B ausgeführt
X findet Fehler in Y
Grundlagen der Informatik I: T12
66
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Teststadien
Sich anbietende Teststrategien
• Unit Test: Test von Codekomponenten, z.B. Code einer Methode,
einer Klasse  strukturelles Testen
• Integrationstest: Test des Zusammenwirkens mehrerer
Codekomponenten  strukturelles Testen
• Systemtest: Test des gesamten Systems gegen die Anforderungen 
funktionales Testen
• Abnahmetest: Test des gesamten Systems mit echten Daten des
Kunden
Grundlagen der Informatik I: T12
67
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Entwicklungsprozess & Testen
Ein ungewollter Teufelskreis …
Zeitdruck
Mehr
Zeitdruck
Mehr
Fehler
Weniger
Tests
Grundlagen der Informatik I: T12
68
Entwicklungsprozess & Testen:
„Agile“ Prozessmethoden
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
• Entwicklung und Testen als verschränkter Prozess
• Testentwicklung vor Produktentwicklung!
• Werkzeugunterstützung benötigt...
Ein wenig
programmieren
Grundlagen der Informatik I: T12
Ein wenig
testen
69
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Motivation Testen: Zusammenfassung
• In der Praxis unverzichtbar
– Je früher Fehler gefunden werden, desto besser
(kostengünstiger)
– Entwicklung ist deshalb typischerweise ein iterativer,
rückgekoppelter Prozess
• Qualität nicht nur überprüfen, sondern, wenn möglich,
„hineinkonstruieren“
– Systematische Verfahren
 Software Engineering
Grundlagen der Informatik I: T12
70
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Testen mit JUnit 4.4
•
•
•
•
•
•
Auf den nächsten Folien testen wir einen Taschenrechner
Die Implementierung ist relativ einfach
Der Taschenrechner arbeitet nur auf int-Werten
Er ist sehr einfach und ineffizient
Außerdem hat er ein paar Bugs
Wir werden sehen, ob JUnit uns bei den Bugs helfen kann!
Grundlagen der Informatik I: T12
71
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die Calculator Klasse (Teil I)
package calc;
public class Calculator {
private static int result;
// Statische Variable fuer Speicherung des Ergebnisses
public void add(int n) {
result = result + n;
}
public void substract(int n) {
result = result - 1;
// Bug: sollte lauten result = result - n
}
public void multiply(int n) { // noch nicht implementiert...
}
public void divide(int n) {
result = result / n;
}
public void square(int n) {
result = n * n;
}
Grundlagen der Informatik I: T12
72
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die Calculator Klasse (Teil II)
public void squareRoot(int n) { // implementieren wir spaeter…
for (; ;) ;
// Bug: unendliche Schleife
}
public void clear() {
// Ergebnis loeschen auf 0
result = 0;
}
public void switchOn() {
// Display anschalten, “Hallo” anzeigen, piepen...
// Was so Geraete heute eben alles tun koennen!
result = 0;
}
public void switchOff() {
// Anzeigen “Tschuess", piepen, Display ausschalten
}
public int getResult() {
return result;
}
}
Grundlagen der Informatik I: T12
73
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Wie testen wir den Calculator?
• Wir wollen jede Operation separat testen
–
–
–
–
–
Add
Substract
Divide
Multiply
Square Root – erst einmal aufgeschoben (Endlosschleife!)
• Wir schreiben eine Testmethode pro Test
• Die Methoden kommen in eine Klasse CalculatorTest
• Tests werden annotiert mit @Test vor dem „public”
• Wir müssen den Rechner vor jedem Test initialisieren
– Müssen “clear()” aufrufen, damit der Wert 0 ist
– Sonst kriegen wir ggf. Folgefehler!
Grundlagen der Informatik I: T12
74
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die CalculatorTest Klasse (Teil I)
package junit4demo;
Packagename ist hier beliebig
Das ist unser Taschenrechner
import calc.Calculator;
import junit.framework.JUnit4TestAdapter;
import static org.junit.Assert.assertEquals;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;
Einige Importe für JUnit
Wir nutzen nur die statische
Methode „assertEquals“
/**
* Basic test class using @Test, @Before and @Ignore annotation
* as well as assert keyword and assertEqual methods
*/
public class CalculatorTest {
private static Calculator calculator = new Calculator(); // this is our calculator!
// Used for backward compatibility (IDEs, Ant and JUnit 3 text runner)
public static junit.framework.Test suite() {
Nötig für ältere
return new JUnit4TestAdapter(CalculatorTest.class);
Umgebungen
}
Grundlagen der Informatik I: T12
75
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die CalculatorTest Klasse (Teil II)
@Before
// must be public not protected like the setup
public void clearCalculator() {
calculator.clear(); // reset value to 0
}
//==================================
//
Test cases
//==================================
@Test
public void add() {
calculator.add(1);
calculator.add(1);
assertEquals(calculator.getResult(), 2);
}
@Before: vor jedem Test
ausgeführt; Calculator ist
damit 0 vor jedem Test
@Test: Annotation für eine
auszuführende Testmethode. Hier
wird überprüft, ob 1+1 = 2 gilt.
Grundlagen der Informatik I: T12
76
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die CalculatorTest Klasse (Teil III)
@Test
public void subtract() {
calculator.add(10);
calculator.substract(2);
assertEquals(calculator.getResult(), 8);
}
@Test
public void divide() {
calculator.add(8);
calculator.divide(2);
assertEquals(calculator.getResult(), 5);
}
Hier wird getestet auf 10-2 = 8
(Fehlschlag durch Bug)
Soll testen auf 8/2=5
(Fehlschlag, da inkorrekt!)
// @Test – deactivated, as it will cause an error (division by 0); more in T16
public void divideByZero() {
Division durch 0 muss einen Fehler
calculator.divide(0);
liefern, sonst schlägt der Test fehl
}
Grundlagen der Informatik I: T12
77
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Die CalculatorTest Klasse (Teil IV)
// @Ignore hat einen String-Parameter, der eine Nachricht anzeigt
@Test
@Ignore("noch nicht testbereit")
Ignoriere den Test von multiply,
public void multiply() {
da der Code noch nicht fertig ist.
calculator.add(10);
calculator.multiply(10);
assertEquals(calculator.getResult(), 100);
}
}
• Kopieren Sie die Klassen von der Homepage
• Stellen Sie sicher, dass JUnit 4.4 installiert ist und als “External
JAR” zum Projekt zugefügt wurde
• Selektieren Sie die Klasse CalculatorTest und wählen Sie Run As
 JUnit Test
• Die Ausgabe sehen Sie auf den nächsten Folien
Grundlagen der Informatik I: T12
78
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
JUnit in Eclipse: Assert-Methoden etc.
Grundlagen der Informatik I: T12
79
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
JUnit in Eclipse: Als Testfall starten
Grundlagen der Informatik I: T12
80
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Fehlerausgabe von JUnit
Kurzfassung der Ergebnisse
Logbuch der Tests
10-2=8 schlug fehl
Grundlagen der Informatik I: T12
81
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Fortgeschrittene Tests
• Wir haben den „divideByZero“-Test nicht genutzt
– Wenn wir dies tun, kommt eine (erwartete) Fehlermeldung!
– Wie man auf das Vorhandensein erwarteter Fehler testet, folgt
zusammen mit der Fehlerbehandlung in T16.
• Wir haben die squareRoot Methode nicht getestet
– Wäre auch keine gute Idee durch die Endlosschleife…
• Wir brauchen eine einmalige allgemeine Initialisierung
– Lege Instanz des Calculator an und schalte ihn an vor den Tests
– Ausschalten, wenn alle Tests fertig sind und freigeben (=null)
• Der nachfolgende Code illustriert das Vorgehen
– Gegenüber der Webseite leicht vereinfacht
Grundlagen der Informatik I: T12
82
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Fortgeschrittene Tests: Set-Up
package junit4demo;
import calc.Calculator;
Externe Klasse sichtbar machen (-> T15)
import junit.framework.JUnit4TestAdapter;
import org.junit.AfterClass;
Einmal ausführen, wenn alle Tests fertig
import static org.junit.Assert.assertEquals;
import org.junit.Before;
Ausführen vor jedem Test
import org.junit.BeforeClass;
import org.junit.Test;
Einmal ausführen vor dem ersten Test
/**
* This test uses advanced fixture and timeout
*/
public class AdvancedTest {
private static Calculator calculator;
// Used for backward compatibility (IDEs, Ant and JUnit 3 text runner)
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(AdvancedTest.class);
}
Grundlagen der Informatik I: T12
83
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Test-Initialisierung und Beendigung
Einmal ausführen bevor Testen beginnt:
@BeforeClass
Rechner anlegen und anschalten
// must be public and static
public static void switchOnCalculator() {
System.out.println("\tSwitch on calculator");
calculator = new Calculator();
calculator.switchOn();
}
Einmal ausführen, wenn alle Tests fertig
@AfterClass
sind: ausschalten und Rechner freigeben
// must be public and static
public static void switchOffCalculator() {
System.out.println("\tSwitch off calculator");
calculator.switchOff();
calculator = null;
}
Grundlagen der Informatik I: T12
84
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Testen mit Timeout
//==================================
//=
Test cases
//==================================
@Test(timeout = 1000)
public void squareRoot() {
calculator.squareRoot(2);
}
@Test
public void square2() {
calculator.square(2);
assertEquals(4, calculator.getResult());
}
// two more tests skipped
}
Test wird fehlschlagen, wenn nicht in
1000ms fertig (Endlosschleifen!)
Testen auf die Quadrate von 4 & 5
Grundlagen der Informatik I: T12
85
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Testausgabe mit Timeout
Testen von squareRoot schlug fehl wegen Timeout
Grundlagen der Informatik I: T12
86
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Mehr zu JUnit...
• JUnit kann (viel) mehr als hier gezeigt
• Das ist aber jenseits des Stoffs der Vorlesung!
• Ein Blick in die Doku lohnt sich
– Mitgeliefertes JavaDoc für JUnit
– Gute Referenz (und Basis dieser Folien):
Antonio Goncalves, Get Acquainted with the New Advanced Features
of JUnit 4
http://www.devx.com/Java/Article/31983/0/page/1
Grundlagen der Informatik I: T12
87