naming conventions for testing

[vjohnslhm]

Beschreibung

Damit der Code übersichtlicher und einheitlicher ist, sollte überlegt werden, Naming Conventions zu befolgen.

Beispiel

Beispiel für Nr. 5 aus der Liste ("Should_ExpectedBehavior_When_StateUnderTest"-Convention) siehe Vorfälle und Vorkommnisse Service:

void should_return_WahlbezirkEreignisseDTO_when_given_valid_wahlbezirkid() {}

statt

void serviceCalled() {}

Argumente

Folgende Vor- und Nachteile die mir einfallen:

+	-
Vereinheitlichung	längere Methodennamen
bessere Lesbarkeit durch klare Struktur	ggf für einige Testfälle schwierig anzuwenden
einfache Identifizierung von Tests

[MrSebastian]

Ergebnis

• Umsetzung ab jetzt
• Je Service ein Umsetzung-Issue
• Update Doku
  • mit Beispielen
• Variante:
  • should_<result>_when_<Input>
  • Result und Input in CamelCase
  • Verwendung von @Nested für die zu testenden Methoden
  • Auch nested für überladene Methoden

[vjohnslhm]

Issues erstellt für die Services Basisdaten (#429), Briefwahl (#430), Broadcast (#431), EAI (#432), Infomanagement (#434), Wahlvorbereitung (#436), und Wahlvorstand (#437).

Die Services Auth, Ergebnismeldung und Monitoring sind noch nciht implementiert, daher sind keine Anpassungstickets notwendig.

Der Service VorfaelleundVorkommnisse wurde bereits umgesetzt (#137)