SWC Zwei

1) Instrumentation: 

- > Byte Code einbauen
-> Offline und on-the-fly

2) Coverage-Types (Verschiedene Typen können gemessen werden)m -> Classes, Methods, Lines, Basic Blocks

3) Report Types (Verschiedener Output wird generiert) -> txt, html, xml

4) Statistics -> Method, class, package, "all classes"

5) Execution -> ant, cmd, eclipse plugin

Refractoring bedeutet:
- bestehenden Code intern verbessern, ohne das äussere Verhalten der Software zu verändern

Also: 

- Code wird sauberer
- verständlicher
- wartbarer
- sicherer
Aber für den Benutzer soll die Software gleich funktionieren

Vorher:
if (s.equals("Hallo")) 
Problem wenn s == null; -> NullPointrException

Nachher: 
if ("Hallo".equals(s)) -> Prüft, ob s = "Hallo"

Refractoring verbessert:
- Lesbarkeit
- Struktur
- Wartbarkeit
- Testbarkeit
- Performance (manchmal)
- SIcherheit gegen Fehler
 

- Ein Hinweis darauf, dass es möglicherweise Probleme im Aufbau oder Design des Codes gibt
Code, der "komisch riecht" und auf schlechte Struktur hindeutet

Wichtig: 
- Code Smell ist nicht unbedingt ein Bug -> Code kann funktionieren, aber er ist:
- Schwer wartbar
- Schlecht lesbar
- Fehleranfällig
- unnötig kompliziert

- Zu lange Methoden
- Duplicate Code
- Large Class
- Zu viele Parameter
- Deep Nesting / Zu viele verschachtelte Ifs
- God Object -> Eine Klasse kontrolleirt alles

- Code Level -> Probleme in einzelnen Methoden oder Codezeilen
- Class Design Level -> Probleme im Aufbau einer Klasse 
- Architectural Design Level -> Probleme in der gesamten Systemarchitektur (Zyklische Abhängikeiten, stark gekoppelte Module etc).

- Sniff out the bad smells in Code
- Code analysieren:
-> Manuell, in dem man den Code durchliest
-> Automatisiert, in dem man Software benutzt -> Checkstyle for Java, Spotbugs for Java, PMD for Java

1) Kontext: Man muss existierenden Code anpassen -> extend/adapt/correct
2) (Bad Solutions) -> Just add new Features
3) Konsequenzen -> Design decays /Qualität nimmt ab, Duplizierter Code, Lange Methoden/grosse Klassen

Gute Lösung:
-> Als erstes Code simpler machen, Code auf Komplexität vorbereiten -> Refractor
-> Neue Features hinzufügen

Konsequenz:
-> Code bleibt Simple
-> Codequalität bleibt hoch

Automated Measures:
- Version Control System (VCS) (Man kann zurück gehen, falls Bugs entstehen)
- Continous Integration (CI) (Man möchte nach dem Refractoring das ganze System testen)
- Tests (Man will schauen, ob man etwas kaputt gemacht hat oder nicht)
- Coding Standards

Social Measures (Absteigender Reihenfolge):
- Collective Ownership (Jeder kann Code ändern)
- Rules of Simplicity
- Sustainable Pace /Nachhaltige Geschwindigkeit
- Pair programming (Driver -> Programmiert tatsächlich, Reviewer: schaut dden Code des Drivers an)
 

- Wenn man systematisch Code entwickelt, trägt man zwei verschiedene Hüte:
1) Function Hat
2) Refractoring Hat

- Man sollte nicht versuchen den Code aufzuräumen, wenn man den "Function Hat" trägt
- Man sollte keine Features hinzufügen, wenn man den "Refractoring Hat" trägt

Siehe Bild

- Bevor oder nachdem man Funktionalität hinzugefügt hat
- Wenn man etwas über den Code gelernt hat
- Als Konsequenz von einem Bug-Fix
- Als Konsequenz von Code Review

- Wenn die Tests nicht vollstädnig durchlaufen (Pass)
- Wenn man den Code re-implementen muss

- Wenn man zu weit geht, Refractoring kann zu unaufhörbarem herumbasteln von Code führen
- Datenbanken können schwierig sein zu refractoren -> Code is easy to change, databases are not
- Refractoring published interfaces können zu Problemen führen für den Code, der das Interface benutzt -> API's sollen nie angepasst werden

- Refractoring verbessert das Design vom System
- Refractoring macht die Software einfacher zu verstehen -> Weil ihre Struktur verbessert wird, weil duplizierter Code entfernt wird
- Refractoring hilft dabei Bugs zu finden -> Weil es ein tiefes Verständnis über den Code fördert
- Refractoring spart Entwicklunsgzeit -> Weil guter Code einfach zu entwickeln ist -> Weil der Code/Das Design robuster ist

Siehe Bild

Verify überprüft ob, wie und welche Methoden eines Mock-Objektes aufgerufen wurden.

Wo?

- auf jedem Modul

- isoliert

- um das Verhalten einer Einheit zu testen

- In einer künstlichen Umgebung laufengelassen

- Ergebnisse werden mit Erwartungswerten (Metriken) verglichen

- Code mit viel Abhängigkeiten
- Code mit komplexer Abhängigkeiten auf andere Infrastrukturen -> Datenbanken, Netzwerke etc

Man Muss die unmitelbare Abhängigkeit loswerden und ersetzen durch Objekte, die man genau kontrollieren kann (Mock)

- Ein Double von Klassen, welche eine bereits vorhandene Klasse ersetzt und sie simuliert

- Ein Objekt oder Komponent, dass nur während des Tests existiert und nur die dasein berechtigung daraus zieht so zu tun, als ob es das echte Objekt wäre, während eines Tests

- Dummy - passed around but never actually used. Usually they just used to fill parameter lists
- Stubs - are minimal implementations of interfaces or base classes. Methods runnning void will typically contain no implementation at all, while methods returning values will typically retun hard-coded values.
- Fates - contains more complex implementations, typically handling interactions between different members of the type it's inheriting
- Mocks - objects pre-programmed with expectations about the methods that will be invoked (aufgerufen)+. The expected arguments for a call and the resulting return valoues or exception.
- Spies - similiar to a mock, but a spy will also record which members were invoked (aufgerufen) so that unit tests can verify that members were invoked as expected (z.B. in welcher Reihenfolge bestimmte Objekte aufgerufen wurden)

- Stub ist ein dummes Objekt
- Ein Objekt, das immer und immer wieder den gleichen Wert zurückgibt
- Erlaubt implementation von Tests ohne production Code

---
class EmailStub implements EmailService{
  void sendMail(String addr, String text){ ...} 
Es ist völlig egal, ob die Mail ankommt

Wir müssen die echten Song-Objekte durch Stub/Mock ersetzen

- In src/test/java

- Mock Objekte simulieren Teile des Verhaltens des echten Objekts (Gibt nicht einfach immer nur den gleichen Rückgabe wert und macht nix
- Klassen können isoliert getestet werden, in dem alle Abhängigkeiten damit kontrolliert werden -> Dabei helfen Mock-Objekte
- Nimmt Klassesn aus der produktiven Umgebung hinaus und bettet sie in eine wohldefinierte Testumgebung -> Nur noch Mock-Objekte sind um das zu testende Objekt, keine echten mehr

- Wenn das echte Objekt nicht determinantisches Verhalten hat (Also ein zufälliges Verhalten)
- Wenn das echte Objekt schwer aufzusetzen/setup ist (z.B. Datenbank mit Setup)
- Wenn das echte Objekt langsam ist (z.B. durch umfangreiche Berechnungen)
- Wenn das echte Objekt ein user-interface hat (Man möchte nur die Logik anschauen)
- Wenn die Tests das echte Objekt fragen müssen, wie es benutzt wurde (if callback function was called) //Wie häufig in welcher Reihenfolge
- Wenn das echte Objekt noch nicht existiert

- Mock Objekte zu schreiben und zu warten ist oftmals aufwändig und ist Fehleranfällig
- Mockito ist eine Bibliothek, welche einen einfachen Weg bietet Mock-Objekte zu erstellen und zu benutzen
- Mockito generiert Mock-Objekte dynamisch während der Laufzeit, es muss also kein Code geschrieben werden und es braucht auch keinen generierten Code

Siehe Bild

Siehe Bild

1) Create -> Erstellt ein Mock-Objekt für ein Interface oder Klasse, welche wir gerne simulieren möchten

2) Specify -> Spezifiziert das erwartete Verhalten von einem Mock-Objekt
3) Use -> Benutzt das Mock-Objekt im normalen/standard unit-testing, als ob es ein normales Objekt wäre
4) Verify -> Überprüft, ob das Mock-Objekt wie erwartet verwendet wurde

- Methode mock(<Class or Interface>) benutzen
- Das Mock-Objekt kann jetzt benutzt werden

---
import static org.mockito.Mockito.*;
/* 
* Create a Mock-Object
*/
Beispiel: 
Song mockSong = mock(Song.class);

- Mock-Objekt lernt, wie es es bei spezifischem Input reagieren soll

/*
* Rückgabewerte werden definiert, indem ein Methodenaufruf mit when() umuschlossen wird. 
* Mit thenReturn() wird festgelegt, welcher Wert zurückgeben werden soll.
*/

Beispiel:
when(mockSong.getTitle()).thenReturn("MySongTitle");
 

- Mock-Objekt kann ganz normal benutzt werden
- Methoden "Behaviour Specification" und "use" können in irgendeiner Reihenfolge sein (no need specify everything before first use)

/*
* Execute Tests
*/
box.addSong(MockSong);
box.playSong("Frozen");

asserEquals("Frozen", box.getCurrenSong().getTitle();