|
@ -133,22 +133,32 @@ Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47 |
|
|
Öffnen Sie das programm `Uebung2.java` im Editor |
|
|
Öffnen Sie das programm `Uebung2.java` im Editor |
|
|
|
|
|
|
|
|
- Starten Sie das Programm mehrfach (_"run as Java Application"_) und geben Sie verschiedenen natürliche Zahlen ein. |
|
|
- Starten Sie das Programm mehrfach (_"run as Java Application"_) und geben Sie verschiedenen natürliche Zahlen ein. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
|
|
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
|
|
|
|
|
|
|
|
- setzen Sie einen BreakPoint in Zeile 40 |
|
|
- setzen Sie einen BreakPoint in Zeile 40 |
|
|
|
|
|
|
|
|
- Starten Sie das Programm wie bisher |
|
|
- Starten Sie das Programm wie bisher |
|
|
|
|
|
|
|
|
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
|
|
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
|
|
|
|
|
|
|
|
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23 |
|
|
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23 |
|
|
|
|
|
|
|
|
- this: **Uebung2@8** |
|
|
- this: **Uebung2@8** |
|
|
- count: **3** |
|
|
- count: **3** |
|
|
|
|
|
|
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this): **this, count, in, out in total 4 mit Zwischenüberschritt** |
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this): **this, count, in, out in total 4 mit Zwischenüberschritt** |
|
|
|
|
|
|
|
|
- in welcher Zeile steht der Debugger? 34->36 |
|
|
- in welcher Zeile steht der Debugger? 34->36 |
|
|
|
|
|
|
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) |
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) |
|
|
|
|
|
|
|
|
- nextInt: **45**, count: **2** |
|
|
- nextInt: **45**, count: **2** |
|
|
|
|
|
|
|
|
- in welcher Zeile steht der Debugger? **40** |
|
|
- in welcher Zeile steht der Debugger? **40** |
|
|
|
|
|
|
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false |
|
|
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false |
|
|
|
|
|
|
|
|
- nextInt: **16**, count: **4** ergebnis: **false** |
|
|
- nextInt: **16**, count: **4** ergebnis: **false** |
|
|
|
|
|
|
|
|
**Beenden Sie den Debugger (_"Terminate"_)** |
|
|
**Beenden Sie den Debugger (_"Terminate"_)** |
|
@ -217,9 +227,11 @@ Lokale Respository |
|
|
|
|
|
|
|
|
- GUI Tests (end to end tests) |
|
|
- GUI Tests (end to end tests) |
|
|
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
|
|
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
|
|
|
|
|
|
|
|
- Integration tests |
|
|
- Integration tests |
|
|
|
|
|
|
|
|
- Component / Contract Tests |
|
|
- Component / Contract Tests |
|
|
|
|
|
|
|
|
- Unit Tests |
|
|
- Unit Tests |
|
|
|
|
|
|
|
|
**Testnamen** |
|
|
**Testnamen** |
|
@ -577,4 +589,164 @@ Schreibe Code im TDD cycle. |
|
|
|
|
|
|
|
|
### Mitteilung |
|
|
### Mitteilung |
|
|
|
|
|
|
|
|
--- |
|
|
|
|
|
|
|
|
-------------------------------------------------------------------------------- |
|
|
|
|
|
|
|
|
|
|
|
## SU (19.01.2023) |
|
|
|
|
|
|
|
|
|
|
|
### Lernziel |
|
|
|
|
|
|
|
|
|
|
|
#### Continous Integration |
|
|
|
|
|
|
|
|
|
|
|
- Relavante Literatur |
|
|
|
|
|
- Bedeutung von CI im Softwareentwicklungsprozess |
|
|
|
|
|
- Aufbau eines CI/CD-Systems |
|
|
|
|
|
- Ablauf des CI-Prozesses |
|
|
|
|
|
- Rolle von automatisierten Tests |
|
|
|
|
|
|
|
|
|
|
|
### Erkenntnise |
|
|
|
|
|
|
|
|
|
|
|
#### Bedeutung von CI im Softwareentwicklungsprozess |
|
|
|
|
|
|
|
|
|
|
|
Größe von Software-Projekten |
|
|
|
|
|
- steigende Komplexität |
|
|
|
|
|
- mehrere Entwickler |
|
|
|
|
|
- Zusammenführen der Einzelleistungen |
|
|
|
|
|
|
|
|
|
|
|
Zusammenführen der Einzelleistungen |
|
|
|
|
|
- Widerspruch Kreativität vs. Konformität |
|
|
|
|
|
- technische Konflikte |
|
|
|
|
|
- persönliche Konflikte |
|
|
|
|
|
- Aufwand |
|
|
|
|
|
|
|
|
|
|
|
Vorteile von CI Systemen |
|
|
|
|
|
- formale Prozesse verringern |
|
|
|
|
|
- automatisierte Prozesse verringern Aufwand |
|
|
|
|
|
- Vorstufe zu Continous Delivery |
|
|
|
|
|
|
|
|
|
|
|
Aufbau eines CI/CD-Systems |
|
|
|
|
|
|
|
|
|
|
|
- Entwicklungsumgebung des Programmierers |
|
|
|
|
|
- Source Code Management System (SCM) |
|
|
|
|
|
- Abhängigkeitenverwaltung |
|
|
|
|
|
- build – Werkzeug |
|
|
|
|
|
- Continous Integration Server |
|
|
|
|
|
- Erweiterungen für Continous Delivery |
|
|
|
|
|
|
|
|
|
|
|
Entwicklungsumgebung des Programmierers |
|
|
|
|
|
|
|
|
|
|
|
Integrated Developement Environment (IDE) |
|
|
|
|
|
- Syntax highlighting |
|
|
|
|
|
- Syntax-Vervollständigung |
|
|
|
|
|
- automatisierte Refactorings |
|
|
|
|
|
- Navigation |
|
|
|
|
|
- Compile–Parameter |
|
|
|
|
|
- Code automatische Formatierung |
|
|
|
|
|
- Fehler-Lokalisierung |
|
|
|
|
|
|
|
|
|
|
|
Source Code Management System (SCM) |
|
|
|
|
|
- Sicherung der Arbeit einzelner Entwickler |
|
|
|
|
|
- zentrale Verfügbarmachung |
|
|
|
|
|
- Zusammenführung parallel geänderter Dateien |
|
|
|
|
|
- parallele Entwicklung verschiedener Features ermöglichen |
|
|
|
|
|
- Zugriff auf dedizierte Stände (releases) |
|
|
|
|
|
- wechsel zwischen Entwicklungsständen |
|
|
|
|
|
|
|
|
|
|
|
Abhängigkeitenverwaltung |
|
|
|
|
|
- nicht selbst im Build-Lauf erzeugt |
|
|
|
|
|
- zentrale Bereitstellung (innerhalb der Organisation) |
|
|
|
|
|
- Zugriff auf einzelne Versionen |
|
|
|
|
|
|
|
|
|
|
|
build – Werkzeug |
|
|
|
|
|
- Übersetzen |
|
|
|
|
|
- Liefer-Artefakte erzeugen |
|
|
|
|
|
- Abhängigkeiten organisieren |
|
|
|
|
|
- automatisierte Tests ausführen |
|
|
|
|
|
- Deploymen |
|
|
|
|
|
|
|
|
|
|
|
Continous Integration Server |
|
|
|
|
|
- SCM überwachen |
|
|
|
|
|
- build-Prozess starten |
|
|
|
|
|
- Ergebnisse berichteten |
|
|
|
|
|
|
|
|
|
|
|
Erweiterungen für Continous Delivery |
|
|
|
|
|
- Staging System |
|
|
|
|
|
- Produktions System |
|
|
|
|
|
|
|
|
|
|
|
Ablauf des CI-Prozesses |
|
|
|
|
|
- Checkin Change |
|
|
|
|
|
- Fetch Change |
|
|
|
|
|
- Build |
|
|
|
|
|
- Test |
|
|
|
|
|
- Ergebnisauswertung |
|
|
|
|
|
- Benachrichtigung |
|
|
|
|
|
|
|
|
|
|
|
Checkin Change |
|
|
|
|
|
- veröffentlichen der Änderung |
|
|
|
|
|
- eigener branch |
|
|
|
|
|
- alle aktuell veröffentlichten Änderungen integriert. |
|
|
|
|
|
- vollständige Änderung |
|
|
|
|
|
- compiliert lokal |
|
|
|
|
|
- automatisierte (Unit–)Tests sind ”grün” |
|
|
|
|
|
- Lieferobjekt kann lokal gebaut werden |
|
|
|
|
|
|
|
|
|
|
|
Fetch Change |
|
|
|
|
|
- Änderungen feststellen |
|
|
|
|
|
- zeitgesteuert |
|
|
|
|
|
- ereignisgesteuert |
|
|
|
|
|
|
|
|
|
|
|
Build |
|
|
|
|
|
- Änderung mit aktuellem Stand integrieren (merge) |
|
|
|
|
|
- compile (Produktivcode und Testcode) |
|
|
|
|
|
|
|
|
|
|
|
Test |
|
|
|
|
|
- nur nach erfolgreichem compile |
|
|
|
|
|
- Testframework starten |
|
|
|
|
|
- Ergebnisse sammeln |
|
|
|
|
|
|
|
|
|
|
|
Ergebnisauswertung |
|
|
|
|
|
- Ermittelt Status von merge, compile und Test |
|
|
|
|
|
- Erfolgsfall: Änderung als neuen aktuellen Stand übernehmen undveröffentlichen |
|
|
|
|
|
- Ergebnisdarstellung als Webseite |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Benachrichtigung |
|
|
|
|
|
- zeitnah |
|
|
|
|
|
- Fehlerfall: Committer |
|
|
|
|
|
- Erfolgsfall: alle |
|
|
|
|
|
- mögliche Wege: |
|
|
|
|
|
- Mail |
|
|
|
|
|
- RSS-Feed |
|
|
|
|
|
- SMS |
|
|
|
|
|
- Twitter |
|
|
|
|
|
- WhatsApp |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rolle von automatisierten Tests |
|
|
|
|
|
- Problem des Continous Integration |
|
|
|
|
|
- Vorteile automatisierter Tests |
|
|
|
|
|
- Grenzen automatisierter Tests |
|
|
|
|
|
|
|
|
|
|
|
Problem des Continous Integration |
|
|
|
|
|
- compilierbar ! = ausführbar |
|
|
|
|
|
- CI soll immer lieferbaren Stand bereit halten |
|
|
|
|
|
- Programm muss im CI Prozess ausgeführt werden |
|
|
|
|
|
|
|
|
|
|
|
Vorteile automatisierter Tests |
|
|
|
|
|
- automatisierte Tests führen Programm aus |
|
|
|
|
|
- dokumentieren gewünschtes Verhalten |
|
|
|
|
|
- sind wiederholbar |
|
|
|
|
|
- erkennen Laufzeitfehler (außer UnitTests) |
|
|
|
|
|
- Ausführungszeit von Arbeitszeit entkoppelt |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Grenzen automatisierter Tests |
|
|
|
|
|
- finden nur Abweichungen von gewünschten/bekanntem Verhalten |
|
|
|
|
|
- finden keine neuen fachlichen Fehler |
|
|
|
|
|
|
|
|
|
|
|
### Kritik |
|
|
|
|
|
|
|
|
|
|
|
### Mitteilung |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------------- |