ANMERKUNG zum weiteren Vorgehen + Test destroyLonelyCell()

This commit is contained in:
Susanne 2025-02-16 15:58:49 +01:00
parent 5c79c16b46
commit c4e026a04b
4 changed files with 42 additions and 2 deletions

View File

@ -51,8 +51,6 @@ public class Life implements ILife {
public ILife nextGeneration() { public ILife nextGeneration() {
Life next = new Life(); 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 y = 0; y < grid.length; y++) {
for (int x = 0; x < grid[y].length; x++) { for (int x = 0; x < grid[y].length; x++) {
if (countAliveNeighbours(x, y) == 3) { if (countAliveNeighbours(x, y) == 3) {

View File

@ -23,6 +23,48 @@ public class LifeTest {
@Test @Test
public void destroyLonelyCell() { public void destroyLonelyCell() {
// Zellen, die weniger als zwei Nachbarn haben, müssen sterben (Einsamkeit). // 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?
} }