Dungeon: Test contrib.entities.ChestTest.checkCreation() schlägt fehl #1622
Comments
Merged
|
done in 31391ea |
cagix
added a commit
that referenced
this issue
Aug 16, 2024
Ich habe mich lange für JUnit 4.x ausgesprochen, u.a. weil sich JUnit5
noch nicht reif für den Praxiseinsatz angefühlte und weil es in JUnit5
keine vernünftige Möglichkeit gab (und gibt), auf Java-Ebene Testsuiten
zu definieren (man muss dann über Gradle o.ä. gehen).
Mittlerweile ist JUnit5 aus meiner Sicht reif genug, um zu wechseln.
Testsuiten kann man zwar immer noch nur extern formulieren, aber davon
machen wir hier im Projekt keinen Gebrauch. Dafür sind die Möglichkeiten
zum Testen auf Exceptions sowie für parametrisierte Tests deutlich
überlegen im Vergleich zu JUnit4.
Let's switch over.
---
Dieser PR führt die Migration von JUnit 4.x auf JUnit 5.x durch.
Betroffen sind:
- Globale Gradle-Konfiguration: Ersetzen der bisherigen
JUnit4-Abhängigkeit durch die neue JUnit5-Abhängigkeit plus Launcher
(lt. Doku wird letzterer nur für IDEs benötigt, die eine veraltete
JUnit-Version mitbringen - brauchen wir die Launcher-Konfiguration
überhaupt?!)
- Gradle-Konfiguration für die Subprojekte "game" und "dungeon":
Hinzunahme der neuen Abhängigkeiten und Deklaration der JUnit-Plattform
für die Tests
- Testsourcen in den Subprojekten "game" und "dungeon":
- Ersetzen der Importe
- Übersetzen von `@Before` und `@After` durch die neuen Annotationen
`@BeforeEach` und `@AfterEach`
- Übersetzen von `@BeforeClass` und `@AfterClass` durch die neuen
Annotationen `@BeforeAll` und `@AfterAll`
- Übersetzen von `@Ignore` durch die neue Annotatione `@Disabled`
- Übersetzen von `@Test(expected = …)` durch den Einsatz von
`Assertions.assertThrows(...)`
- **Anpassen der Assertions**: Es wurde an einigen Stellen
`assertEquals(string, expected, actual)` verwendet. Das gibt es so nicht
mehr bzw. der String müsste als letzter Parameter übergeben werden. Da
die verwendeten Strings in der überwiegenden Mehrzahl semantisch unklar
und nur eine Wiederholung des erwarteten Wertes waren (Beispiel:
`assertEquals("es sollte 3 rauskommen", 3, something.or.other())`), habe
ich diese Strings einfach überall entfernt. Es gab einige wenige
Stellen, wo die Strings tatsächlich eine sinnvolle semantische Aussage
enthielten. Wenn jemand Zeit hat, könnte man diese Strings nochmal
wieder einbauen.
- ~~Der **Test `contrib.entities.ChestTest.checkCreation()` schlägt auf
einmal fehl**. Wenn ich mir den Test anschaue, frage ich mich, warum der
nicht auch bereits in vorher (also in JUnit4) fehlgeschlagen ist? =>
Issue #1622~~ fixed: tausche `assertEquals` gegen die korrekte Methode
für den Use-Case: `assertArrayEquals`
(31391ea).
---
closes #1583
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Nach der Migration auf JUnit5 schlägt der Test
contrib.entities.ChestTest.checkCreation()fehl. Ich frage mich allerdings, wieso dieser Test überhaupt jemals grün war? Hier werden zwei Objekt-Arrays direkt miteinander verglichen - und da es verschiedene Objekte (mit dem selben semantischen Inhalt) sind, schlägt der Test fehl. Das sollte mal behoben werden.siehe auch #1621 (comment)
The text was updated successfully, but these errors were encountered: