diff --git a/out/production/GameOfLifeAssignment/Life.class b/out/production/GameOfLifeAssignment/Life.class
index 881fc9b..7c5d211 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 426c495..82df7e4 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 8e3411c..0e7c963 100644
--- a/src/Life.java
+++ b/src/Life.java
@@ -38,8 +38,7 @@ public class Life implements ILife {
 
   @Override
   public void setDead(int x, int y) {
-    // TODO Auto-generated method stub
-
+    grid[x][y] = false;
   }
 
   @Override
@@ -55,6 +54,8 @@ public class Life implements ILife {
       for (int x = 0; x < grid[y].length; x++) {
         if (countAliveNeighbours(x, y) == 3) {
           next.setAlive(x, y);
+        } else if (countAliveNeighbours(x, y) < 2) {
+          next.setDead(x, y);
         }
       }
     }
diff --git a/test/LifeTest.java b/test/LifeTest.java
index 56cf88b..4b1340c 100644
--- a/test/LifeTest.java
+++ b/test/LifeTest.java
@@ -24,29 +24,6 @@ public class LifeTest {
     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);
@@ -57,14 +34,6 @@ public class LifeTest {
 
         // 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?
     }