ANMERKUNG zum weiteren Vorgehen + Test destroyLonelyCell()
This commit is contained in:
parent
5c79c16b46
commit
c4e026a04b
Binary file not shown.
Binary file not shown.
@ -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) {
|
||||
|
@ -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?
|
||||
}
|
||||
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user