# Team Europa: Naming Conventions

Version: 11 | Last modified: 2026-02-02T11:46:28.363+01:00
Source: confluence page ID 402097097

---

Branch-ConventionstrueAQuA Branch rulesfalse600autotoptrue14024091
Dauerhafte BranchesdevelopmentÂ enthÃ¤lt zu jedem Zeitpunkt den letzten Stand der abgeschlossenen Issues, d.h. Arbeit an Features, Enablern und Bugs werden nach Abschluss per Merge Request auf diesen Branch gebracht. Im Fall von Hotfixes werden diese auch nach Abschluss Ã¼berÂ releaseÂ zurÃ¼ck nachÂ developmentÂ gebracht.
VonÂ releaseÂ (frÃ¼herÂ main) erstellen wir am Ende jeder Iteration ein Release durch Setzen eines Tags, nachdem wir den Stand vonÂ developmentÂ dorthin gemergt haben.

Regeln fÃ¼r temporÃ¤re BranchesBranches fÃ¼r Hotfixes zweigen vonÂ releaseÂ ab und tragen das PrÃ¤fixÂ hotfix/. Auf diese Weise sind sie nicht nur als Hotfixes leichter erkennbar, es lÃ¤sst sich auch im GitLab konfigurieren, dass Merge Requests fÃ¼r Hotfixes per Default zurÃ¼ck nachÂ releaseÂ gehen. Von dort mergen wir dann weiter zurÃ¼ck nachÂ development.
Branches fÃ¼r die Arbeit an Jira-Issues (Features, Enablers oder Bugs, die keine Hotfixes sind) verwenden das PrÃ¤fixÂ ticket/Â und werden vonÂ developmentÂ abgezweigt. In GitLab konfigurieren wir, dass Merge Requests von diesen Branches per Default zurÃ¼ck nachÂ developmentÂ gehen. Die Information, um welche Art von Issue es sich handelt, ist nun nicht mehr redundant im Branchnamen enthalten, ist an der Stelle aber auch nicht nÃ¶tig.
Branches fÃ¼r Arbeiten ohne Issue verwenden als PrÃ¤fixÂ no-ticket/. Sie werden wie Issue-Branches vonÂ developmentÂ abgezweigt und per Default dorthin gemergt.
Durch Tools erstellte Branches, wie z.B. durch den Renovate Bot, erhalten einen Bezeichner des Tools als PrÃ¤fix, wie z.B.Â renovate/, und werden per Merge Request nachÂ developmentÂ gemergt.

Auf das PrÃ¤fix folgt bei Branches, die sich auf ein Issue beziehen, die ID des Issues sowie eine durch Bindestriche gekoppelte kurze Beschreibung des Inhalts, also z.B.Â IFPRPR-112-map-calendar-attributes. Bei Branches ohne Issue verwenden wir nach dem PrÃ¤fix aussagekrÃ¤ftigen Kurzbezeichnung, z.B.Â add-ktlint
Wichtig: Bei Commits auf den temporÃ¤ren Branches beachten wir dieÂ AQuA: Konventionen fÃ¼r Commit-Messages.
Suffixe fÃ¼r API-KlassenDer AGS verwendet diverse Schemata fÃ¼r JSON-Daten, z.B. Produktions- und VertriebsauftrÃ¤ge jeweils in den DomÃ¤nen Vertrieb und Fahrplan, die wir umgangssprachlich APIs nennen und die in Form von OpenAPI-Spezifikationen vorliegen. FÃ¼r die Verarbeitung der Daten nutzen wir Code, der mit einerÂ ifpGenerateApiClient Gradle-Task generiert wird (siehe z.B. Submodul produktionsauftrag-api-fahrplan). Bei der Konfiguration der Task kann ein modelNameSuffix angegeben werden, der an alle Namen von generierten Klassen angehÃ¤ngt wird. Dieses Suffix sollten wir fÃ¼r alle APIs durchgÃ¤ngig einheitlich gestalten, so dass am Namen einer Klasse ihr Ursprung abgelesen werden kann, mit dem Ziel, den Code, der API-Klassen nutzt, leichter verstÃ¤ndlich zu machen, und um Fehlern vorzubeugen.
Ein Suffix sollte deshalb im Regelfall aus zwei Teilen bestehen:
Einem KÃ¼rzel fÃ¼r die Gesamtmenge der enthaltenen Nachrichten. Aktuell verwenden wir Pa fÃ¼r Produktions- und Va fÃ¼r VertriebsauftrÃ¤ge. KÃ¼nftig wÃ¤re z.B. Bpe oder Pe fÃ¼r (Bau-)Planungsergebnisse im unterjÃ¤hrigen Bau denkbar.
Einem Bezeichner fÃ¼r den Kontext - i.d.R. die DomÃ¤ne - dem die API entstammt. Aktuell verwenden wir Vertrieb und Fahrplan fÃ¼r eben diese beiden DomÃ¤nen.
Als Kombination ergeben sich dann insgesamt z.B. ErstanmeldungMessagePaVertrieb und PathInformationVaFahrplan als Klassennamen.
Dies sollte im Allgemeinen alles sein, ein weiteres AnhÃ¤ngsel wieÂ DtoÂ fÃ¼gt nur unnÃ¶tiges Rauschen hinzu, da das Vorhandensein eines Suffixes ohnehin schon signalisiert, dass es sich um eine API- und damit DTO-Klasse handelt.
Commit Messages und Titel von Merge-RequestssieheÂ 
Tests und TestvariablenVariablen innerhalb von Tests folgen diesen Konventionen:
Test-Inputs bekommen den PrÃ¤fixÂ given
Erzeugte Ergebnisse (typischerweise der RÃ¼ckgabewert der getesteten Methode) bekommen den PrÃ¤fixÂ actual
Erwartete Ergebnisse (typischerweise das, wogegen dieÂ actual-Werte verglichen werden) bekommen den PrÃ¤fixÂ expected
Das zu testende System (typischerweise ein Service oder eine anderweitige Spring-Komponente, aber mÃ¶glicherweise auch eine (Extension- oder statische) Funktion) bekommt den PrÃ¤fixÂ tested.
Gemockte Komponenten bekommen den PrÃ¤fixÂ mock. Dies wird sinnvoll adaptiert fÃ¼r mock-Ã¤hnliche Komponenten (Spys, ...)
Der Mehrwert, der hierdurch gewonnen werden soll, ist, dass innerhalb eines Tests eindeutig auf einen Blick identifiziert werden kann, welches das getestete System und welches nur Hilfestellungen fÃ¼r den Test sind.
Codebeispiel(exemplarisch, nicht realer Code mit vielen Auslassungen)
java
 @Spy
 var spyAngebotstrasseMessageService : MessageService 

 fun `receiving Fertigmeldung should trigger sending Angebotrasse`(
 val givenFertigmeldung: Fertigmeldung, // or string of JSON
 val givenZugtrasse: Zugtrasse,
 val expectedAngebotstrasse: Angebotstrasse
 ) {
 // Arrange
 when(mockAngebotstrassenRepository.getByFertigmeldung(givenFertigmeldung)).thenReturn(givenZugtrasse)

 // Act
 spyFertigmeldungMessageService.send(givenFertigmeldung)
 
 // Assert
 assertEquals(true, spyAngebotstrasseMessageService.hasNext())
 val actualAngebotstrasse = spyAngebotstrasseMessageService.receive()
 Â  Â  Â  Â assertEquals(false, spyAngebotstrasseMessageService.hasNext())
 assertEquals(expectedAngebotstrasse, actualAngebotstrasse)

 val actualAllAngebotstrassen = testedAngebotstrassenService.getAllAngebotstrassen()
 assertEquals(1, actualAllAngebotstrassen.size)
 }
}]]>
