# Review live
## Team Dichte, Kießler, Rudevica

Ein Codereview soll nun nicht den anderen Code niedermachen, sondern das soll hier nun nur dafür dienen, wo man sich verbessern kann!
Also bitte nicht persönlich nehmen, sondern eher als eine Chance von Erfahrungen zu profitieren!

Checkliste haben wir anfangs genutzt um vieles erstmal zu finden,
fanden aber ein reines Durcharbeiten mit ja, ne, ja nicht sinnvoll,
daher hatten wir uns danach für die Anforderungen via Userstories entschieden,
die aber ja auch größtenteils einfach nur mit erfüllt oder teilweise erfüllt durchgearbeitet wären,

aber da wir doch das eine oder andere nicht funktionale an Anforderungen gefunden haben,

haben uns aber nun für eine Präsentation direkt am Code hier entschieden.

kurz zu den Userstories

Also das ist das Projekt in seiner Strukur welches wir bekommen haben.

## 1. Es fehlt komplette Java OrdnerStruktur Convention over Configure
also hier
src/main/java/ -> hier die Main.java
src/main/ressoruces -> hier die Dateien, die extern für das Programm benötigt werden (z.B. ex01.md)

src/test/java/ -> hier der Ordner für jede Klasse (in gleicher Ordnerstruktur) die getestet werden
src/test/ressources -> hier alle benötigten externen Files für das ausführen der Tests

## 2. Relative Pfade
Relative Pfade nutzen, damit jeder damit arbeiten kann ohne den Code immer für sich anpassen zu müssen wie hier in der Main sichtbar

## 3. Interface
- Was ist die Idee gewesen, was soll das Ziel des Interfaces sein?
- Es wird dieses Interface nirgendwo weiter genutzt und daher unklar, warum vorhanden. War das Ziel der Erweiterbarkeit? Wenn ja, in welchem Bereich? Oder Erleichterung zum Aufbau einer Testumgebung? (1 Verantwortlicher schreibt die Klasse, ein anderer die Tests und man einigt sich auf diese Schnittstellen?)
- zusätzliche Information:
meistens werden Interfaces nach adjektiven benannt wie flyable oder so, um zu zeigen das ein Objekt auch fliegen kann (implements flyable)

## 4. Single Point or Responsibility

Wenn man versucht zu erklären, was eine Klasse macht, und dort die Wörter “und” oder “oder” nutzen kann, sollte man überlegen, diese Klasse weiter zu splitten.
In diesem Fall habt ihr hier eine Klasse Bedinungsüberdeckung,

1. welche aus einem MD File eine Wahrheitstabelle ausliest
2. UND entscheidet, was zu tun ist, wenn eine CoverageMethode ausgewählt wurde
3. UND welche die MMBUE Bedinungsüberdeckung auf eine Wahrheitstabelle anwenden kann
4. UND welche die MCDC Bedingungsüberdeckung auf eine Wertetabelle angewendet wird
5. UND das Ergebnis dann wieder in eine Datei gespeichert

Das bedeutet das diese Datei ziemlich viele Verantwortungen hat.
- Wenn man nun in einem Team arbeitet und jeder implementiert davon nun 1 Verantwortung, muss bei Fehlern erst geschaut werden, wer dafür Verantwortlich ist (Bedinungsüberdeckung in Zeile 921 ist nicht klar).
- Dann müss geprüft werden warum:
- 1 Grund könnte dann ein Seiteneffekt sein
- oder weil 2 verantwortliche zur Bearbeitung eine Klassenattribut von gleichen Namen gesetzt haben und beide dann darauf gearbeitet haben

Daher ist es ratsam auf Verantwortungen in mehrere Klassen auszulagern, damit sowas vermieden werden kann.

## 5. Konstruktor mit überflüssigen Übergabeparameter
hier: Konstruktor mit Pfad -> aber eigentlich ist das egal, weil do while eh den Wert beim laden immer übergeben bekommt.
*zeigen was erstellt wurde*

## 6. Objektattribute nutzen
hier: Beim Laden wird ein Array zurückgegeben, schiebt ihr danach wieder rein in das gleiche Objekt-> kann also auch direkt bei dem Objekt vorgehalten werden.

## 7. System.exitcode(0) bedeutet ohne Fehler
ihr wolltet aber hier ja abbrechen mit Fehler und sagt ned warum

## 8. Try Catch Ressource seit java 8 -> neue Variante die eigentlich seit java 8 genutzt werden sollte

## 9. deutsch oder englisch
(Methodennamen und Parameternamen) bsp throwExc und vergroessereArray

## 10. auswertungslänge zählt Anzahl an Werte, die ausgelesen wurden aus Datei,
aber warum -1 nicht in Methode, da es ja eine spezifische Sache von MD File ist?

## 11. Namensgebung
in diesem Fall könnte man also die Methode also auch genauer beschreiben, das aus MD die Auswertungslänge gezählt werden
haben aber noch weitere Beispiele, wo wir später drauf zurück kommen

## 12. Throw Exc-Methode
Was ist der Gedanke der Nutzung von ThrowExc?
- Auslagerung der Fehler mit Message nicht unbedingt sinnvoll, dann kann man an der Stelle auch direkt die Exception schmeißen. Hat auch den Vorteil, den Text individuell aussagekräftiger zu konstruieren
- “Da ist ein Datei-Fehler” ist nicht aussagekräftig.
- Besser wären Nachrichten in dem Format
- “Einlesefehler: Beim Einlesen der 4. Zeile der Datei xy ist ein Fehler aufgetreten”
- oder “Einlesefehler: Konnte Datei xy nicht finden”
zumal irreführend mit sovielen Integerwerten dann später zurechtzukommen (war es nun 826 oder 827)

## 13. Gültigkeit-Methode

Was ist die Idee von boolean Gueltigkeit(wahrheitstabelle)?
- Es wird die Methode ausgeführt, und sollte sie true zurückgeben, dann findet ein System.out.println statt?!?
- Ziel der Methode ist vermutlich die Prüfung, ob es keine Duplikate an Testcases gibt. Dazu wurde ein StringArray erstellt, welches alle atomaren Teile als 1 Element hinzufügt und anschließend überprüft, indem durch alle Elemente durchitteriert wird und überprüft, ob kein nachfolgendes Element dem gerade zu prüfenden Element entspricht.
- Wenn auf Duplikate geprüft werden soll, empfiehlt sich immer ein Array in ein Set zu werfen und zu vergleichen, ob deren Size/Length gleich groß sind, wenn keine weitere Reperatur def gefundenen Duplikate gewünscht ist.

## 14. Namensgebung
Namensgebung eurer AusgabeDateien ist unglücklich gewählt
wenn die Dateien “ex3.md”, “ex2.md”, “ex1.md” in dieser Reihenfolge geprüft werden, dann bekommt
- die “ex3.md” als Ausgabe z.B. “mcdc coverage1.md”
- die “ex2.md” als Ausgabe z.B. “mcdc coverage2.md”
- und die “ex1.md” als Ausgabe “mcdc coverage3.md”

## 15. prüfe-Wahheit-Methode
Was ist die Idee hinter Methode prüfeWahheit()?
- Vermutung: Die aus Datei ausgelesene Tabelle wird um 1 Spalte erweitert. In dieser letzten Spalte wird eine 1 gesetzt, wenn die Bedinungsüberdeckung diesen Testcase als benötigt makieren will. Nachdem für MMBUE geprüft wurde, sollte diese Methode wohl die letzte Spalte wieder “reseten”, damit bei der Prüfung zu MCDC die Spalte nicht noch einträge von MMBUE hat.
- Wahrheitstabelle ist kein Attribut des Bedinungsüberdeckungs-Objektes, auf dem gearbeitet wird, daher muss dieser nicht angepasst werden. Des weiteren wäre sonst sehr empfehlenswert, wenn es die Ressourcen des Programmausführenden Systems zulassen, ein Attribut extra pro Bedinungsüberdeckung zu erstellen statt ein Attribut für alle, damit man dann auch Seiteneffekte verhindert.
- Als Tip vielleicht nochmal anschauen, wie der Lebenslauf von Variablen sind. Die Wahheitstabelle übergebt ihr einer Methode. Diese Methode nutzt nun diesen übergebenen Wert und dekonstruiert ihn im Anschluß nach Abschluß der Methode.
- prüfeWahrheit() hat als Rückgabewert eine Tabelle, und mit diesem zurückgegebene Wert wird nichts weiter gemacht. Also lasst ihr die Methode was berechnen und zurückgeben, ohne damit dann weiter zu arbeiten
- Wenn möglich, niemals übergebene Parameter modifizieren. Erstellt einfach ein neues Objekt und modifiziert diese. Erleichtert auch die Wartbarkeit, falls die Methode nocheinmal überarbeitet werden muss, und man dafür ggf diese übergebenen Werte brauch. In einer kleinen Methode ist dies vielleicht noch nachvollziebar, sollte diese Methode aber komplexer werden, erkennt man ggf Fehler erst später, da man nicht gesehen hat, das die Parameter modifiziert wurden.

# Thema Tests
## 16. outsourcen Testumgebung
Was ist der Gedanke Testumgebung auszusorcen in init(int)?
- Man will sehen wie bei einem Test die Testumgebung aufgebaut wird um dann mit Methodenaufruf zu verlgeichen um nachzuvollziehen was wie verglichen wird. ein init(1) ist da eher kontraproduktiv, da nicht leicht erkennbar ist, was wie kontrolliert wird.
also init und direkt eine assert-Zeile ist nicht leicht leserlich

## 17. Kein test der 2 andere Test durchführt

## 18. Test sind immer void

## 19. Fehlerbehandlung prüfen bei Tests