diff --git a/out/production/GameOfLifeAssignment/Life.class b/out/production/GameOfLifeAssignment/Life.class
index 7557f17..881fc9b 100644
Binary files a/out/production/GameOfLifeAssignment/Life.class and b/out/production/GameOfLifeAssignment/Life.class differ
diff --git a/out/test/GameOfLifeAssignment/LifeTest.class b/out/test/GameOfLifeAssignment/LifeTest.class
index 64c6df1..426c495 100644
Binary files a/out/test/GameOfLifeAssignment/LifeTest.class and b/out/test/GameOfLifeAssignment/LifeTest.class differ
diff --git a/src/Life.java b/src/Life.java
index 74abc63..8e3411c 100644
--- a/src/Life.java
+++ b/src/Life.java
@@ -51,8 +51,6 @@ public class Life implements ILife {
   public ILife nextGeneration() {
     Life next = new Life();
 
-    // Refactoring: erst wurde nur Zelle 1,1 (entsprechend dem Testfall) überprüft,
-    // jetzt auf alle Zellen des grids ausgeweitet
     for (int y = 0; y < grid.length; y++) {
       for (int x = 0; x < grid[y].length; x++) {
         if (countAliveNeighbours(x, y) == 3) {
diff --git a/test/LifeTest.java b/test/LifeTest.java
index 1e1124f..56cf88b 100644
--- a/test/LifeTest.java
+++ b/test/LifeTest.java
@@ -23,6 +23,48 @@ public class LifeTest {
     @Test
     public void destroyLonelyCell() {
         // Zellen, die weniger als zwei Nachbarn haben, müssen sterben (Einsamkeit).
+
+
+
+        // ----- ANMERKUNG -----
+
+        // Nach dem Schreiben und Ausführen dieses Tests, habe ich den bisher bestehenden Code so verstanden,
+        // dass die Zellen ja mit jeder neuen Generation standardmäßig als 'tot' initialisiert werden,
+        // solange man nicht ausdrücklich zuvor sagte, die Zelle soll leben.
+        // Sprich lebende Zellen aus der alten Generation werden zunächst nicht in die Folgegeneration vererbt und
+        // dort dann geschaut, ob diese noch sterben müssen.
+        //
+        // Demnach bin ich an diesem Punkt nun etwas verwirrt um die generelle Notwendigkeit einer setDead()-Methode,
+        // werde sie sowie die übrigen Tests und Funktionen aber dennoch implementieren. Jedoch ist es möglich,
+        // dass ich nun die TDD-Methodik weniger gezielt anwenden werde. Grund hierfür ist, dass ich es auch als
+        // sinnfrei empfinde, den Code gezielt entsprechend zu manipulieren, nur damit der Test erzwungenermaßen failed.
+        //
+        // Zudem ist nach der Ausarbeitung, also dem Refactoring des Codes (jedenfalls war das meine Intention dabei)
+        // anhand des ersten Testfalls ja nun bereits sämtliche nötige Logik implementiert.
+        //
+        // Also ist mein Ziel nun wie gesagt, dass ich nach bestem Wissen und Gewissen alles weiterhin schrittweise
+        // implementieren werde, aber es möglich ist, dass mMn redundante Zwischenschritte fehlen könnten.
+
+
+
+        // Arrange: lebende Zelle (1,1) hat weniger als zwei Nachbarn und sollte sterben.
+        Life l = new Life();
+        l.setAlive(1, 1);
+        l.setAlive(0, 0);
+
+        // Act: Berechnung der Folgegeneration
+        ILife nextGen = l.nextGeneration();
+
+        // Assert: Zelle (1,1) sollte tot sein
+        assertFalse(nextGen.isAlive(1, 1));
+
+
+        // Was für destroyCell eigentlich, wozu setDead generell??? Die Zelle wird doch sowieso in der nextGen mit
+        // false initalisiert, solange sie nicht explizit als true (mittels setAlive) initialisiert werden soll.
+        // Deshalb wird der Test ja sogar jetzt ohne setDead-Implementierung grün.
+        //
+        // Ich muss doch nie eine Zelle aktiv mit setDead destroyen, wenn sie in der Folgegeneration sowieso immer
+        // zu Anfang tot ist, solange ich sie nicht aktiv belebe?
     }