429 tests naming basisdaten #811
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe changes introduce a new dependency in the Maven configuration and adjust formatting in the project’s pom file. A new architectural test file has been added. In addition, a large number of test method names across various files have been systematically refactored. The renaming follows a descriptive naming convention that clearly indicates the expected outcome and conditions (for example, renaming generic names to formats like “should_return…when…”). These updates affect test classes related to clients, mappers, validators, repository behavior, security configurations, integration tests, and service operations across different modules such as Handbuch, Kopfdaten, Referendumvorlagen, Wahlbezirke, Wahldaten, Wahltage, and Wahllokalsystem. Import statements were also reintroduced or reorganized where needed. No changes to the underlying test logic or functionality have been made; the modifications are purely on method names and formatting for improved clarity. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchValidatorTest.java (1)
99-160:⚠️ Potential issueFix incorrect test method names that don't match their behavior.
The test methods expect exceptions to be thrown when validating invalid models, but their names incorrectly suggest that no exceptions should be thrown. This makes the tests misleading and harder to understand.
Update the method names to match their behavior:
-void should_notThrowException_when_modelIsNull() +void should_throwException_when_modelIsNull() -void should_notThrowException_when_handbuchReferenceIsNull() +void should_throwException_when_handbuchReferenceIsNull() -void should_notThrowException_when_handbuchReferenceWahltagIDIsNull() +void should_throwException_when_handbuchReferenceWahltagIDIsNull() -void should_notThrowException_when_handbuchReferenceWahltagIDIsEmptyString() +void should_throwException_when_handbuchReferenceWahltagIDIsEmptyString() -void should_notThrowException_when_handbuchReferenceWahltagIDIsBlankString() +void should_throwException_when_handbuchReferenceWahltagIDIsBlankString() -void should_notThrowException_when_handbuchReferenceWahlbezirksArtIsNull() +void should_throwException_when_handbuchReferenceWahlbezirksArtIsNull() -void should_notThrowException_when_handbuchDataIsNull() +void should_throwException_when_handbuchDataIsNull() -void should_notThrowException_when_handbuchDataHasZeroLength() +void should_throwException_when_handbuchDataHasZeroLength()wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SecurityConfigurationTest.java (1)
100-114: 💡 Verification agent🧩 Analysis chain
Consider adding CSRF validation tests for GET endpoints.
While the tests comprehensively cover authorization scenarios, they're missing explicit CSRF validation tests for non-GET endpoints. Although GET requests are CSRF-safe by default, it's good practice to verify CSRF protection for POST, PUT, and DELETE endpoints.
Let's verify the CSRF protection implementation:
Also, let's verify if there are any endpoints that might need additional CSRF protection:
Also applies to: 116-130, 132-158, 160-186, 188-202, 204-230, 232-245
🏁 Script executed:
#!/bin/bash # Search for CSRF configuration in the codebase rg -l "csrf\(\)" --type javaLength of output: 5493
🏁 Script executed:
#!/bin/bash # Search for controller endpoints that might need CSRF protection ast-grep --pattern 'class $_ { $$$ @$_Mapping($$$) $$$ }'Length of output: 65
Action: Augment CSRF Test Coverage for Non-GET Endpoints
The current tests in the SecurityConfigurationTest file only exercise GET endpoints—which are inherently CSRF safe. However, our review confirmed that there are no explicit tests verifying CSRF protection for non-GET endpoints (e.g., POST, PUT, DELETE) in this file. While many other modules do include CSRF-related tests (as seen by the occurrences of “csrf()” in various integration tests), this particular file and its nested test classes lack coverage for endpoints where CSRF protection is critical.
- Issue Found: No explicit CSRF validation tests for POST, PUT, and DELETE endpoints in the observed SecurityConfigurationTest.
- Recommendation: Add tests that invoke non-GET requests without a CSRF token (and with one) to ensure that disallowed requests are correctly rejected while valid requests succeed.
🧹 Nitpick comments (45)
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchServiceSecurityTest.java (1)
76-76: LGTM! Consistent test naming pattern.The renamed test methods in the
SetHandbuchclass maintain the same BDD naming convention:
should_grantAccess_when_authoritiesArePresentshould_denyAccess_when_serviceAuthoritiyIsMissingshould_returnTechnischeWlsException_when_repoAuthorityIsMissingThe names clearly indicate the expected outcomes and their triggering conditions, improving test readability.
Note: There's a minor typo in the word "serviceAuthoritiyIsMissing" (extra 'i'), but since this PR's focus is on standardizing naming patterns and the meaning remains clear, this can be addressed in a separate PR if desired.
Also applies to: 84-84, 92-92
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltageServiceSecurityTest.java (1)
54-54: LGTM! Clear and descriptive test method names.The renamed test methods follow a consistent "should_[expected outcome]when[condition]" pattern that clearly communicates the test's purpose and conditions. This improves code readability and maintainability.
Consider adding a test class-level documentation comment explaining the test naming convention for future contributors. For example:
/** * Security tests for WahltageService. * Test methods follow the naming convention: should_[expected outcome]_when_[condition] */ @SpringBootTest(classes = MicroServiceApplication.class)Also applies to: 69-69
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/UnicodeConfigurationTest.java (1)
63-63: Consider a more descriptive test method name.While the new name follows the
should_[expected outcome]_when_[condition]pattern, it could be more descriptive of the actual test behavior. Consider renaming to:- void should_testForNfcNormalization_when_givenComposedString() { + void should_normalizeToComposedUnicode_when_persistingDecomposedString() {This better reflects that the test verifies Unicode normalization during persistence.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerIntegrationTest.java (1)
40-49: Consider adding tests for unsupported HTTP methods.Based on our experience with similar endpoints, consider adding tests to verify that unsupported HTTP methods (POST, PUT, DELETE) return appropriate error responses.
Here's an example implementation:
@Test void should_return405_when_callingAsyncProgressWithPost() throws Exception { val request = MockMvcRequestBuilders.post("/businessActions/asyncProgress"); mockMvc.perform(request) .andExpect(status().isMethodNotAllowed()); } @Test void should_return405_when_callingAsyncProgressWithPut() throws Exception { val request = MockMvcRequestBuilders.put("/businessActions/asyncProgress"); mockMvc.perform(request) .andExpect(status().isMethodNotAllowed()); } @Test void should_return405_when_callingAsyncProgressWithDelete() throws Exception { val request = MockMvcRequestBuilders.delete("/businessActions/asyncProgress"); mockMvc.perform(request) .andExpect(status().isMethodNotAllowed()); }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenControllerIntegrationTest.java (2)
192-192: Fix typo in method name.The word "communication" is misspelled as "comunication" in the method name.
- void should_returnTechnischeWlsException_when_comunicationWithEaiFailedAndKopfdatenNotFound() throws Exception { + void should_returnTechnischeWlsException_when_communicationWithEaiFailedAndKopfdatenNotFound() throws Exception {
79-261: Consider adding test cases for edge scenarios.The test coverage is good but could be enhanced by adding tests for:
- Response when the external service returns malformed data
- Behavior when the external service times out
- Handling of concurrent requests
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerTest.java (1)
26-38: Consider adding HTTP method tests.Based on our learnings from similar async progress endpoints, we should also test the allowed HTTP methods for this endpoint.
Add a test method to verify that only GET is allowed:
@Test void should_allowGetMethod_when_callingAsyncProgress() { // Test that only GET method is allowed // Similar to other AsyncProgressController tests in the project }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/KopfdatenRepositoryTest.java (1)
49-50: Simplify the test method name for better readability.While the new name follows BDD style, it could be more concise by:
- Removing the redundant "AND"
- Avoiding the repetition of "WahlID"
Consider this more readable alternative:
- public void should_deleteAllByBezirkUndWahlIDANDByWahlID_when_callingDeleteAll() { + public void should_deleteAllByBezirkAndWahlID_when_callingDeleteAll() {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerIntegrationTest.java (1)
4-4: Consider adding test coverage for error scenarios.While the test naming has been improved, there appears to be no test coverage for scenarios where the reset operation fails. Consider adding test cases for error scenarios.
Example test name:
should_returnTechnischeWlsException_when_resetOperationFailswls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenValidatorTest.java (1)
31-31: Consider rephrasing the test name for better readability.The current name
should_throwNoException_when_modelIsValidcould be more naturally phrased asshould_notThrowException_when_modelIsValid.- void should_throwNoException_when_modelIsValid() { + void should_notThrowException_when_modelIsValid() {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlModelMapperTest.java (1)
29-29: LGTM! Clear and descriptive test name.The new method name follows the established naming convention and clearly describes the test's purpose and expectations.
Consider enhancing test coverage by adding edge cases such as empty lists and null inputs. This would make the test suite more robust.
Example test names:
void should_returnEmptyList_when_givenEmptyWahlEntityList() void should_throwNullPointerException_when_givenNullInput()wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltagModelMapperTest.java (1)
50-64: Consider enhancing test data and documentation.While the test implementation is solid, consider these improvements:
- The test data in
createWahltagListandcreateWahltagModelListcould use more meaningful dates and descriptions that reflect real-world scenarios.- Consider adding class-level documentation to describe the mapping rules being tested.
Example improvement for test data:
private List<Wahltag> createWahltagList() { - val wahltag1 = new Wahltag("identifikatorWahltag1", LocalDate.now().minusMonths(2), "beschreibungWahltag1", "nummerWahltag1"); + val wahltag1 = new Wahltag( + "wahltag2023", + LocalDate.of(2023, 9, 10), // Specific election date + "Bundestagswahl 2023", // Real-world description + "BTW2023" // Meaningful identifier + );wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenValidatorTest.java (1)
128-130: Consider renaming the helper method for clarity.The helper method
createEmptyWahlModelcould be more descriptive about its purpose in the test context.Consider renaming to better reflect its role:
- private WahlModel createEmptyWahlModel() { + private WahlModel createWahlModelWithNullValues() { return new WahlModel(null, null, null, null, null, null, null, null); }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineServiceTest.java (1)
61-62: Consider being more specific about the exception type in the test name.For consistency with other test methods (like
should_throwTechnischeWlsException_when_savingFailed), consider renaming toshould_throwTechnischeWlsException_when_noDataFoundto explicitly specify the exception type.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/nfcconverter/NfcConverterTest.java (2)
75-79: LGTM! Consider updating the test documentation.The new method name follows the standardized "should_[action]when[condition]" pattern and clearly describes the test's purpose. Consider updating the documentation comment to match the new naming style:
- // Test, das Request mit konfigriertem ContentType auf NFC normalisiert wird. + // Verifies that a request is filtered (normalized to NFC) when the content type is in the whitelist
103-108: LGTM! Consider updating the test documentation.The new method name follows the standardized "should_[action]when[condition]" pattern and clearly describes the test's purpose. Consider updating the documentation comment to match the new naming style:
- // Test, das Request nicht konfigriertem ContentType auf unverändert bleibt, d.h. nicht - // auf NFC normalisiert wird. + // Verifies that a request is not filtered when the content type is not in the whitelistwls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenServiceTest.java (1)
45-47: Consider adding more test cases for edge scenarios.The test coverage could be enhanced by adding test cases for:
- Invalid input validation
- Empty or malformed referendum data
- Concurrent access scenarios
Would you like me to help generate additional test cases for these scenarios?
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/handbuch/HandbuchControllerTest.java (1)
76-76: Consider renaming to better reflect the test's purpose.The current name
should_throwNoException_when_requestIsSentToServicefocuses on the absence of exceptions, but the test primarily verifies that the service method is called with correct parameters (as seen in the verify statement at line 90).Consider renaming to:
- void should_throwNoException_when_requestIsSentToService() throws IOException { + void should_callServiceWithCorrectParameters_when_requestIsSentToService() throws IOException {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/nfcconverter/NfcHelperTest.java (1)
36-48: Consider enhancing test readability with @DisplayName and parameterized tests.While the test implementation is solid, consider these improvements:
- Add
@DisplayNameannotations to provide even more readable test output- Use
@ParameterizedTestto combine similar test cases, particularly for the NFD/NFC character pairsExample implementation:
@DisplayName("NFC converter should properly convert NFD strings") @ParameterizedTest @MethodSource("nfdNfcPairs") void should_useNfcConverter_when_givenString(String nfd, String nfc) { assertEquals(nfc, NfcHelper.nfcConverter(nfd)); assertEquals(nfc.length(), NfcHelper.nfcConverter(nfd).length()); } static Stream<Arguments> nfdNfcPairs() { return Stream.of( Arguments.of(FIRST_NFD, FIRST_NFC), Arguments.of(SECOND_NFD, SECOND_NFC), Arguments.of(THIRD_NFD, THIRD_NFC) ); }Also applies to: 50-60
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerTest.java (2)
51-63: Add assertion to verify the "Ok" response.The test name suggests that it verifies an "Ok" response, but the test only verifies that the service method is called. Consider adding an assertion to validate the response status.
void should_returnOk_when_serviceIsCalled() { val wahltagID = "wahltagID"; val requestBody = List.of(Mockito.mock(WahlDTO.class)); val mockedMappedRequest = List.of(Mockito.mock(WahlModel.class)); Mockito.when(wahlDTOMapper.fromListOfWahlDTOtoListOfWahlModel(requestBody)).thenReturn(mockedMappedRequest); - unitUnderTest.postWahlen(wahltagID, requestBody); + val response = unitUnderTest.postWahlen(wahltagID, requestBody); Mockito.verify(wahlenService).postWahlen(new WahlenWriteModel(wahltagID, mockedMappedRequest)); + Assertions.assertThat(response.getStatusCode().is2xxSuccessful()).isTrue(); }
69-74: Add assertion to verify the "Ok" response.Similar to the previous test, the test name suggests that it verifies an "Ok" response, but the test only verifies that the service method is called. Consider adding an assertion to validate the response status.
void should_returnOk_when_serviceIsCalled() { - unitUnderTest.resetWahlen(); + val response = unitUnderTest.resetWahlen(); Mockito.verify(wahlenService).resetWahlen(); + Assertions.assertThat(response.getStatusCode().is2xxSuccessful()).isTrue(); }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineControllerIntegrationTest.java (1)
52-163: Consider adding tests for edge cases.While the test coverage is good for main success and error paths, consider adding tests for edge cases such as:
- Maximum size file uploads
- Empty file uploads
- Special characters in wahltagID
- Different file formats or corrupted CSV data
Would you like me to help generate test cases for these scenarios?
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineDTOMapperTest.java (2)
33-39: Improve test name accuracy.While the new name follows the convention, it could be more precise:
- The test verifies a property of UngueltigeWahlscheineReferenceModel, not WahlbezirkModel.
- The parameter is a single DTO, not multiple DTOs.
Consider renaming to:
- void should_returnWahlbezirkModel_when_givenWahlbezirkArtDTOs(final WahlbezirkArtDTO art) + void should_returnUngueltigeWahlscheineReferenceModel_with_matchingWahlbezirksart_when_givenWahlbezirkArtDTO(final WahlbezirkArtDTO art)
45-54: Consider including all input parameters in the test name.While the new name follows the convention and is clear, it could be more complete by mentioning all required input parameters.
Consider renaming to:
- void should_returnUngueltigeWahlscheineWriteModel_when_givenUngueltigeWahlscheineReferenceModel() + void should_returnUngueltigeWahlscheineWriteModel_when_givenReferenceModelAndByteData()wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlDTOMapperTest.java (1)
35-36: Consider moving this test to a separate nested class.While the new name
should_returnWahlModelList_when_givenWahlDTOListis clear and follows the convention, this test method appears to be misplaced. It tests the DTO-to-Model conversion but is located in theFromListOfWahlModelToListOfWahlDTOnested class, which suggests Model-to-DTO conversion tests.Consider moving this test to a new nested class named
FromListOfWahlDTOToListOfWahlModelto better organize the test cases:@Nested class FromListOfWahlModelToListOfWahlDTO { @Test void should_returnNull_when_givenNull() { // ... } @Test void should_returnWahlDTOList_when_givenWahlModelList() { // ... } +} + +@Nested +class FromListOfWahlDTOToListOfWahlModel { @Test void should_returnWahlModelList_when_givenWahlDTOList() { // ... } }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceTest.java (2)
99-99: Consider making the test name more specific.While the new name follows the convention, it could be more specific about which service method is being called. Consider renaming to
should_returnSavedData_when_postWahlenIsCalledto better reflect the specific service method being tested.
177-177: Consider making the test name more specific.While the new name follows the convention, it could be more specific about which service method is being called. Consider renaming to
should_resetData_when_resetWahlenIsCalledto better reflect the specific service method being tested.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceSecurityTest.java (1)
142-142: Fix typo in method name while maintaining clear naming.The renamed methods follow the clear
should_action_when_conditionpattern, but there's a typo in one method name.Fix the typo in the method name:
- void should_denyAccess_when_serviceAuthoritiyIsMissing() { + void should_denyAccess_when_serviceAuthorityIsMissing() {Also applies to: 148-148, 155-155
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenServiceSecurityTest.java (1)
47-49: Consider adding class-level documentation.While the test methods are now clearly named, consider adding JavaDoc to the nested test class to document the overall test scenarios and setup requirements.
Add documentation to explain the test class purpose:
@Nested + /** + * Tests for the getKopfdaten operation, focusing on security aspects: + * - Access control with different authority combinations + * - Behavior with empty and non-empty repository states + */ class GetKopfdaten {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeServiceTest.java (1)
47-73: Consider extracting test setup into helper methods.While the tests are well-structured and thorough, they contain repetitive setup code. Consider extracting common setup patterns into helper methods to improve readability and maintainability.
For example:
- Setup of mock data and responses
- Common verification steps
Example refactor:
+ private WahltagModel setupWahltagModel(String wahltagID, LocalDate date) { + return new WahltagModel(wahltagID, date, "", ""); + } + + private void setupCommonMocks(WahltagModel wahltag, List<Wahlbezirk> entities, + List<WahlbezirkModel> models) { + Mockito.when(wahlbezirkRepository.findByWahltag(wahltag.wahltag())) + .thenReturn(entities); + Mockito.when(wahlbezirkModelMapper + .fromListOfWahlbezirkEntityToListOfWahlbezirkModel(entities)) + .thenReturn(models); + } @Test void should_loadDataFromRemote_when_notExistingInRepo() { val wahltagID = "_identifikatorWahltag3"; - val wahltagDate = LocalDate.now(); - val wahltag = new WahltagModel(wahltagID, wahltagDate, "", ""); + val wahltag = setupWahltagModel(wahltagID, LocalDate.now()); // ... rest of the test setup ... - Mockito.when(wahlbezirkRepository.findByWahltag(wahltag.wahltag())) - .thenReturn(mergedWahlbezirkEntitiesFromRepo); - Mockito.when(wahlbezirkModelMapper - .fromListOfWahlbezirkEntityToListOfWahlbezirkModel( - mergedWahlbezirkEntitiesFromRepo)) - .thenReturn(mergedWahlbezirkeWithWahlen); + setupCommonMocks(wahltag, mergedWahlbezirkEntitiesFromRepo, + mergedWahlbezirkeWithWahlen);Also applies to: 75-103
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchValidatorTest.java (2)
32-32: Consider using consistent verb forms in test method names.For better readability and consistency with other test methods, consider using "throw" consistently:
-void should_notThrowException_when_modelIsValid() { +void should_throw_no_exception_when_modelIsValid() {
18-25: Consider adding documentation and reducing duplication.The test class has good structure and coverage, but could be improved:
- Add class-level documentation explaining the validation rules being tested.
- Consider extracting common test data setup to reduce duplication between nested classes.
Add documentation and extract common setup:
+/** + * Tests for HandbuchValidator which validates: + * - Handbuch references must have non-null/non-blank wahltagID and wahlbezirksArt + * - Handbuch write operations must have valid reference and non-empty handbuchData + */ class HandbuchValidatorTest { + // Common test data + private static final String VALID_WAHLTAG_ID = "wahltagID"; + private static final WahlbezirkArtModel VALID_WAHLBEZIRK_ART = WahlbezirkArtModel.BWB;wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeControllerIntegrationTest.java (1)
182-241: Consider improving test data setup.The
createClientWahlvorschlaegeDTOmethod could be enhanced for better maintainability:
- Consider using a builder pattern for clearer test data construction
- Move test data creation to a separate test data factory class
- Use constants for test data values
Example refactor using a builder pattern:
- private de.muenchen.oss.wahllokalsystem.basisdatenservice.eai.aou.model.WahlvorschlaegeDTO createClientWahlvorschlaegeDTO(final String wahlID, - final String wahlbezirkID) { - val stimmzettelgebietID = "stimmzettelgebietID"; - - val clientWahlvorschlaegeDTO = new de.muenchen.oss.wahllokalsystem.basisdatenservice.eai.aou.model.WahlvorschlaegeDTO(); - clientWahlvorschlaegeDTO.setStimmzettelgebietID(stimmzettelgebietID); - clientWahlvorschlaegeDTO.setWahlID(wahlID); - clientWahlvorschlaegeDTO.setWahlbezirkID(wahlbezirkID); - // ... rest of the method - } + @TestConfiguration + static class TestDataFactory { + private static class WahlvorschlaegeDTOBuilder { + private String wahlID; + private String wahlbezirkID; + private String stimmzettelgebietID = "stimmzettelgebietID"; + + public WahlvorschlaegeDTOBuilder wahlID(String wahlID) { + this.wahlID = wahlID; + return this; + } + + public WahlvorschlaegeDTOBuilder wahlbezirkID(String wahlbezirkID) { + this.wahlbezirkID = wahlbezirkID; + return this; + } + + public de.muenchen.oss.wahllokalsystem.basisdatenservice.eai.aou.model.WahlvorschlaegeDTO build() { + val dto = new de.muenchen.oss.wahllokalsystem.basisdatenservice.eai.aou.model.WahlvorschlaegeDTO(); + dto.setStimmzettelgebietID(stimmzettelgebietID); + dto.setWahlID(wahlID); + dto.setWahlbezirkID(wahlbezirkID); + dto.setWahlvorschlaege(createWahlvorschlaege()); + return dto; + } + + private Set<WahlvorschlagDTO> createWahlvorschlaege() { + // ... create wahlvorschlaege + } + } + + public static de.muenchen.oss.wahllokalsystem.basisdatenservice.eai.aou.model.WahlvorschlaegeDTO createClientWahlvorschlaegeDTO( + String wahlID, String wahlbezirkID) { + return new WahlvorschlaegeDTOBuilder() + .wahlID(wahlID) + .wahlbezirkID(wahlbezirkID) + .build(); + } + }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/archunit/ArchUnitTest.java (5)
20-20: Add documentation for the regex pattern.The regex pattern enforces the test naming convention but could benefit from documentation explaining:
- The expected format with examples
- Any limitations or edge cases
- The reasoning behind specific pattern choices
Add a comment block above the pattern:
+ /** + * Regex pattern for test method names following the convention: + * should_[whatIsBeingTested]_when_[condition] + * + * Examples: + * - should_returnUser_when_validIdProvided + * - should_throwException_when_dataNotFound + */ private static final String REGEX_TEST_CASE_NAME = "^should_([a-z]+([A-Z]+[a-z]*)+)_when_([a-z]+([A-Z]+[a-z]*)+)$";
22-24: Enhance test method detection.The rule currently only checks methods annotated with
@Testbut misses@ParameterizedTestmethods. Also, the constant name is quite verbose.Consider these improvements:
- private static final MethodsShouldConjunction RULE_TEST_NAMING_CONVENTION_SHOULD_WHEN_MATCHED = methods() + private static final MethodsShouldConjunction TEST_NAMING_RULE = methods() .that().areAnnotatedWith(Test.class) + .or().areAnnotatedWith(ParameterizedTest.class) .should().haveNameMatching(REGEX_TEST_CASE_NAME);
28-31: Add error handling for package import.The setup method should handle potential failures during package import, as ClassFileImporter might fail if the package structure is incorrect or classes are inaccessible.
Consider adding error handling:
@BeforeEach void setUp() { - serviceClasses = new ClassFileImporter().importPackages(MicroServiceApplication.class.getPackage().getName()); + try { + serviceClasses = new ClassFileImporter().importPackages(MicroServiceApplication.class.getPackage().getName()); + } catch (Exception e) { + throw new IllegalStateException("Failed to import service classes for architectural testing", e); + } }
35-37: Add validation for ArgumentsAccessor.The test method should validate the ArgumentsAccessor to ensure it contains the expected arguments before accessing them.
Consider adding validation:
void should_verifyArchUnitRuleForAllClassesOfService_when_running(final ArgumentsAccessor arguments) { + if (arguments == null || arguments.size() < 2) { + throw new IllegalArgumentException("Test requires both rule name and ArchRule instance"); + } + if (!(arguments.get(1) instanceof ArchRule)) { + throw new IllegalArgumentException("Second argument must be an ArchRule instance"); + } arguments.get(1, ArchRule.class).check(serviceClasses); }
39-42: Consider adding more architectural rules.While the test naming convention rule is a good start, consider adding more architectural rules to verify other aspects of the codebase.
Examples of additional rules to consider:
public static Stream<Arguments> rulesToVerify() { return Stream.of( - Arguments.of("TEST_NAMING_CONVENTION_RULE", RULE_TEST_NAMING_CONVENTION_SHOULD_WHEN_MATCHED)); + Arguments.of("TEST_NAMING_CONVENTION_RULE", RULE_TEST_NAMING_CONVENTION_SHOULD_WHEN_MATCHED), + // Additional rules to consider: + // Arguments.of("LAYER_DEPENDENCIES_RULE", layerDependenciesRule), + // Arguments.of("PACKAGE_STRUCTURE_RULE", packageStructureRule), + // Arguments.of("EXCEPTION_HANDLING_RULE", exceptionHandlingRule)); }wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/BasisdatenValidatorTest.java (1)
109-109: Consider breaking down the test into smaller, more focused test cases.While the new name correctly follows the convention and fixes typos, the length of the method name suggests this test might be covering too many conditions. Consider splitting it into separate test cases for each relationship:
- One for Basisstrukturdaten-Wahl relationship
- One for Basisstrukturdaten-Wahlbezirk relationship
- One for Basisstrukturdaten-Stimmzettelgebiet relationship
This would improve readability and make the test cases more focused.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/DummyClientImplTest.java (3)
96-104: Consider extracting date assertions into helper method.While the test name is clear, the implementation could be more readable by extracting the date assertions into a helper method.
@Test void should_makeSureAllUnderobjectsHaveTheRequestedDate_when_givenProperData() { val aDate = LocalDate.now(); val result = unitUnderTest.loadBasisdaten(new WahltagWithNummer(aDate, "0")); - Assertions.assertThat(result.basisstrukturdaten()).allMatch(bsd -> bsd.wahltag().equals(aDate)); - Assertions.assertThat(result.wahlen()).allMatch(w -> w.wahltag().equals(aDate)); - Assertions.assertThat(result.wahlbezirke()).allMatch(wbz -> wbz.wahltag().equals(aDate)); - Assertions.assertThat(result.stimmzettelgebiete()).allMatch(szg -> szg.wahltag().equals(aDate)); + assertAllEntitiesHaveWahltag(result, aDate); } + +private void assertAllEntitiesHaveWahltag(BasisdatenResult result, LocalDate expectedDate) { + Assertions.assertThat(result.basisstrukturdaten()) + .allMatch(bsd -> bsd.wahltag().equals(expectedDate)); + Assertions.assertThat(result.wahlen()) + .allMatch(w -> w.wahltag().equals(expectedDate)); + Assertions.assertThat(result.wahlbezirke()) + .allMatch(wbz -> wbz.wahltag().equals(expectedDate)); + Assertions.assertThat(result.stimmzettelgebiete()) + .allMatch(szg -> szg.wahltag().equals(expectedDate)); +}
107-116: Consider a more concise test name.While the new name follows the convention, it could be more concise without losing meaning.
-void should_returnNonNullObjectWithActivePropertyTrue_when_callingGet() { +void should_returnActiveWahltag_when_called() {
118-126: Consider a more specific test name.The new name could be more specific about what type of data is being returned.
-void should_returnNonEmptyField_when_callingGet() { +void should_returnNonEmptyWahlbezirke_when_called() {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceTest.java (1)
126-126: Consider a more precise test name.While the current name follows the convention, it could be more specific about the actual behavior being tested.
Consider this alternative that better describes the test's purpose:
- void should_notPreventFromResultObject_when_exceptionIsPersisted() { + void should_returnOriginalModel_when_persistenceFails() {wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineValidatorTest.java (1)
98-98: LGTM! Test method names consistently follow the established pattern.The renaming maintains consistency with the first class and improves test documentation.
Consider adding these test cases for better coverage:
- Test with empty byte array for
ungueltigeWahlscheineData- Test with zero-length byte array for
ungueltigeWahlscheineData+ @Test + void should_returnException_when_ungueltigeWahlscheineDataIsEmpty() { + val invalidModel = initValidModel().ungueltigeWahlscheineData(new byte[]{}).build(); + + Mockito.when(exceptionFactory.createFachlicheWlsException(ExceptionConstants.POSTUNGUELTIGEWS_PARAMETER_UNVOLLSTAENDIG)) + .thenReturn(mockedWlsException); + + Assertions.assertThatThrownBy(() -> unitUnderTest.validUngueltigeWahlscheineWriteModelOrThrow(invalidModel)) + .isSameAs(mockedWlsException); + }Also applies to: 105-105, 113-113, 123-123, 134-134, 144-144, 154-154, 164-164
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SecurityConfigurationTest.java (1)
1-30: Consider organizing imports for better readability.The static imports are separated from regular imports, which is good. However, consider grouping related imports together (e.g., all Spring Security related imports).
- import static de.muenchen.oss.wahllokalsystem.basisdatenservice.TestConstants.SPRING_TEST_PROFILE; - import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.csrf; - import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.delete; - import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get; - import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.multipart; - import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post; - import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.put; - import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status; + // Test Constants + import static de.muenchen.oss.wahllokalsystem.basisdatenservice.TestConstants.SPRING_TEST_PROFILE; + + // Spring Security + import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.csrf; + + // Spring Test + import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*; + import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (84)
wls-basisdaten-service/pom.xml(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/archunit/ArchUnitTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/DummyClientImplTest.java(10 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/KonfigurierterWahltagClientImplTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/KonfigurierterWahltagClientMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlbezirkeClientImplTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlbezirkeClientMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahldatenClientImplTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahldatenClientMapperTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlenClientImplTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlenClientMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahltageClientImplTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahltageClientMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlvorschlaegeClientImplTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlvorschlaegeClientMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SecurityConfigurationTest.java(6 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SwaggerConfigurationTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/UnicodeConfigurationTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/UserInfoAuthoritiesServiceTest.java(6 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/nfcconverter/NfcConverterTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/nfcconverter/NfcHelperTest.java(7 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/KopfdatenRepositoryTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahlRepositoryTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahlbezirkRepositoryTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahltagRepositoryTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/common/FileMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/handbuch/HandbuchControllerIntegrationTest.java(6 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/handbuch/HandbuchControllerTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenControllerIntegrationTest.java(7 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenControllerTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenDTOMapperTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenControllerIntegrationTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenControllerTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenDTOMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineControllerIntegrationTest.java(8 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineControllerTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineDTOMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkDTOMapperTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkeControllerIntegrationTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkeControllerTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlDTOMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerIntegrationTest.java(10 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageControllerIntegrationTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageControllerTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageDTOMapperTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerIntegrationTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeControllerIntegrationTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeControllerTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeDTOMapperTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchModelMapperTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchServiceSecurityTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchServiceTest.java(6 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchValidatorTest.java(11 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/BasisdatenValidatorTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenModelMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenServiceSecurityTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenServiceTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenValidatorTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenModelMapperTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenServiceSecurityTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenServiceTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenValidatorTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineModelMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineServiceSecurityTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineServiceTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineValidatorTest.java(10 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkModelMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeServiceSecurityTest.java(4 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeServiceTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeValidatorTest.java(1 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlModelMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceSecurityTest.java(7 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceTest.java(6 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenValidatorTest.java(8 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltagModelMapperTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltageServiceSecurityTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltageServiceTest.java(3 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltermindaten/AsyncProgressTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeModelMapperTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceSecurityTest.java(2 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceTest.java(5 hunks)wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeValidatorTest.java(1 hunks)
✅ Files skipped from review due to trivial changes (5)
- wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenDTOMapperTest.java
- wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/KonfigurierterWahltagClientMapperTest.java
- wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltermindaten/AsyncProgressTest.java
- wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeModelMapperTest.java
- wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineControllerTest.java
🧰 Additional context used
🧠 Learnings (4)
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerTest.java (2)
Learnt from: MrSebastian
PR: it-at-m/Wahllokalsystem#642
File: wls-ergebnismeldung-service/src/test/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/rest/awerte/AsyncProgressControllerIntegrationTest.java:41-53
Timestamp: 2024-12-12T08:08:50.977Z
Learning: In our Java Spring project, for endpoints like `/businessActions/asyncProgress` in `AsyncProgressController`, we only test the allowed HTTP methods (e.g., GET) and do not test unsupported HTTP methods.
Learnt from: MrSebastian
PR: it-at-m/Wahllokalsystem#642
File: wls-ergebnismeldung-service/src/test/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/rest/awerte/AsyncProgressControllerTest.java:30-38
Timestamp: 2024-12-12T08:07:53.510Z
Learning: Unhandled exceptions are managed by the `GlobalExceptionHandler` class, and tests for exception handling are added in `AsyncProgressControllerIntegrationTest`.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerIntegrationTest.java (1)
Learnt from: MrSebastian
PR: it-at-m/Wahllokalsystem#642
File: wls-ergebnismeldung-service/src/test/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/rest/awerte/AsyncProgressControllerIntegrationTest.java:41-53
Timestamp: 2024-12-12T08:08:50.977Z
Learning: In our Java Spring project, for endpoints like `/businessActions/asyncProgress` in `AsyncProgressController`, we only test the allowed HTTP methods (e.g., GET) and do not test unsupported HTTP methods.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/DummyClientImplTest.java (1)
Learnt from: MrSebastian
PR: it-at-m/Wahllokalsystem#621
File: wls-ergebnismeldung-service/src/main/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/client/DummyClientImpl.java:27-46
Timestamp: 2024-12-06T14:40:02.820Z
Learning: In the `DummyClientImpl` class (`wls-ergebnismeldung-service/src/main/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/client/DummyClientImpl.java`), which is a dummy class used for testing purposes, input parameter validation is not required.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SecurityConfigurationTest.java (1)
Learnt from: MrSebastian
PR: it-at-m/Wahllokalsystem#621
File: wls-ergebnismeldung-service/src/test/java/de/muenchen/oss/wahllokalsystem/ergebnismeldungservice/configuration/SecurityConfigurationTest.java:116-143
Timestamp: 2024-12-06T14:46:34.146Z
Learning: In `SecurityConfigurationTest.java`, the tests are designed to validate access with authorized and unauthorized users only. Other scenarios, such as invalid input data, are tested in other classes.
🔇 Additional comments (182)
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenControllerTest.java (1)
32-32: Great improvement in test naming!The new method name
should_callServiceAndMapObjects_when_callingGetfollows a clear and descriptive naming convention that makes the test's purpose immediately apparent. This aligns well with the PR's objective of standardizing test naming conventions.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlvorschlaegeClientMapperTest.java (2)
24-25: Great improvement in test method naming!The new method name clearly describes the expected behavior and test conditions, following BDD naming conventions. This makes the test's purpose immediately clear and aligns well with the PR's objective of standardizing test naming conventions.
88-89: LGTM!The formatting changes maintain code readability without affecting functionality.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkeControllerIntegrationTest.java (1)
101-101: LGTM! Test method names are now more descriptive and follow a consistent pattern.The renaming of test methods follows the "should_[expected outcome]when[condition]" pattern, which makes the test purposes immediately clear:
loadedFromExternal()→should_returnWahlbezirkDTOList_when_loadedFromExternal()externalDataIsPersisted()→should_returnWahlbezirkDTOList_when_externalDataIsPersisted()repoHasPriorityForRemoteOnLoad()→should_prioritizeRepo_when_loadedFromRemote()technischeWlsExceptionWhenNoExternalDataFound()→should_returnTechnischeWlsException_when_noExternalDataFound()This improves readability and aligns with the PR's objective of standardizing test naming conventions.
Also applies to: 129-130, 156-156, 192-192
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenModelMapperTest.java (1)
17-17: Great job on the test method renaming!The new test method names follow a clear and consistent "should_return[Output]_when_given[Input]" pattern that makes the test purpose immediately clear. This improves readability and maintainability by:
- Clearly indicating the expected output
- Explicitly stating the input conditions
- Following a standardized naming convention across all test methods
Also applies to: 39-39, 53-53
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlbezirkeClientMapperTest.java (2)
22-23: LGTM! Clear and descriptive test method name.The new method name follows BDD naming conventions and clearly communicates both the expected outcome and test conditions.
51-52: LGTM! Consistent test naming pattern.The new method name maintains consistency with the BDD naming pattern and effectively describes the test's purpose.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlenClientImplTest.java (1)
46-46: Great job on improving test method names!The renamed test methods now follow a clear and consistent BDD-style naming convention (
should_[expected behavior]_when_[condition]). This makes the test intentions immediately obvious and improves the test suite's documentation value.Also applies to: 63-63, 74-74
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenControllerTest.java (1)
35-35: LGTM! The new test name improves clarity.The renamed test method
should_returnReferenceDTO_when_serviceIsCalledfollows the standardized naming convention and accurately describes the test's purpose. The implementation correctly validates that a reference DTO is returned when the service is called.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchServiceSecurityTest.java (2)
6-7: LGTM!The added imports for
HandbuchandHandbuchRepositoryare correctly placed and necessary for the test class.
47-47: LGTM! Clear and descriptive test method names.The renamed test methods in the
GetHandbuchclass follow the behavior-driven development (BDD) naming convention:
should_grantAccess_when_authoritiesArePresentshould_failAuthorization_when_anyAuthorityIsMissingThese names clearly describe the expected behavior and conditions, making the test's purpose immediately apparent.
Also applies to: 59-59
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeServiceSecurityTest.java (1)
66-66: Great improvement in test method naming!The new method names follow a clear "should_[expectedOutcome]when[condition]" pattern that makes the test's purpose immediately obvious:
should_grantAccess_when_authoritiesArePresentshould_denyAccess_when_anyAuthorityIsMissingAndRepoIsEmptyshould_denyAccess_when_anyAuthorityIsMissingAndRepoHasDataThis naming convention significantly improves readability and helps developers quickly understand the test scenarios.
Also applies to: 84-84, 108-108
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageControllerTest.java (1)
31-32: LGTM! Great improvement in test naming.The renamed test method follows BDD naming conventions and clearly communicates:
- Expected outcome: return WahltagDTOList
- Condition: when service is called
The test implementation demonstrates good practices with clear arrange-act-assert pattern, proper mocking, and immutable variables.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkModelMapperTest.java (2)
14-15: LGTM! Clear and descriptive test method name.The new name follows the "should_when" pattern and clearly describes the test's purpose, making it more maintainable.
24-25: LGTM! Clear and descriptive test method name.The new name follows the "should_when" pattern and clearly describes the test's purpose, making it more maintainable.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahldatenClientMapperTest.java (1)
22-22: Great improvement in test method naming!The rename from
isMappedtoshould_returnBasisdatenModel_when_givenBasisdatenDTOfollows BDD naming conventions and clearly communicates:
- The expected outcome: returning a BasisdatenModel
- The test conditions: given a BasisdatenDTO
This makes the test's purpose immediately clear and improves maintainability.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/UnicodeConfigurationTest.java (1)
14-15: LGTM!The reintroduced imports are necessary for the test implementation.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahltagRepositoryTest.java (2)
6-6: LGTM!The re-added imports are necessary for the test functionality:
MicroServiceApplicationfor the Spring Boot test configurationvalfor concise variable declarations in the test data setupAssertionsfor test assertionsAlso applies to: 14-14, 15-15
42-42: LGTM! Clear and descriptive test method name.The new method name follows BDD style naming convention (should_[expected outcome]when[condition]), making the test's purpose and behavior immediately clear. This aligns well with the PR's objective of standardizing test naming conventions.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenServiceTest.java (3)
51-51: LGTM! Clear and descriptive test method name.The new name follows the "should_[expected outcome]when[condition]" pattern, making the test's purpose immediately clear.
77-77: LGTM! Consistent test naming pattern.The new name maintains the "should_[expected outcome]when[condition]" pattern, providing clear test intent.
65-65: LGTM! Minor formatting improvement.The indentation adjustment enhances code readability.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerIntegrationTest.java (1)
41-41: LGTM! Method name follows the naming convention.The new method name
should_returnCurrentAsyncProgress_when_callingAsyncProgressclearly describes the expected outcome and condition, following the established pattern.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkDTOMapperTest.java (2)
19-19: LGTM! Clear and descriptive test name.The new test name
should_returnNull_when_givenNullfollows a clear naming convention that effectively communicates both the expected outcome and the test condition.
24-24: LGTM! Clear and descriptive test name.The new test name
should_returnWahlbezirkDTOList_when_givenWahlbezirkModelListfollows a clear naming convention that effectively communicates both the expected outcome and the test condition.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahltageClientImplTest.java (4)
44-45: LGTM! Clear and descriptive test name.The renamed test method
should_mapClientResponse_when_callingGetfollows the BDD naming convention and clearly describes both the expected behavior and the test condition.
61-62: LGTM! Improved test name clarity.The renamed test method
should_throwFachlicheWlsException_when_givenNullclearly indicates the expected exception and the condition that triggers it.
71-72: LGTM! Enhanced test name readability.The renamed test method
should_throwTechnischeWlsException_when_apiInvocationFailedprecisely describes the expected technical exception when API communication fails.
26-105: Well-structured test class with improved naming.The test class demonstrates good testing practices with proper organization, mocking, and assertions. The new test method names enhance readability by clearly describing the expected behavior and test conditions, making it easier to understand test coverage at a glance.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageDTOMapperTest.java (2)
20-20: Great improvement in test method naming!The new name
should_returnNull_when_givenNullfollows BDD naming conventions and clearly communicates both the expected outcome and test condition, making the test's purpose immediately clear.
25-25: Excellent test name refactoring!The new name
should_returnWahltagDTOList_when_givenWahltagModelListprecisely describes the test's purpose, following BDD naming conventions and making the expected behavior crystal clear.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenDTOMapperTest.java (2)
22-22: Great improvement in test method naming!The new method name follows BDD naming conventions and clearly communicates both the expected outcome and test conditions, making the test's purpose immediately clear.
51-51: Excellent test name refactoring!The new method name follows the same clear BDD pattern and effectively communicates the test's purpose and expectations.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/kopfdaten/KopfdatenControllerIntegrationTest.java (1)
83-83: LGTM! Test method names are now more descriptive and follow a consistent pattern.The renaming of test methods to follow the "should_[expected outcome]when[condition]" pattern greatly improves readability and understanding of test purposes.
Also applies to: 114-114, 147-147, 169-169, 192-192, 216-216, 239-239
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlbezirke/WahlbezirkeControllerTest.java (2)
4-4: Import organization looks good.
34-34: Great improvement in test method naming!The new name
should_returnWahlbezirkDTOList_when_serviceIsCalledclearly communicates the test's purpose and follows the standardized naming convention, making it easier to understand the expected behavior.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltermindaten/AsyncProgressControllerTest.java (1)
30-30: LGTM! The method name is now more descriptive.The new name
should_returnCurrentProgressStateAsDTO_when_callingAsyncProgressclearly indicates both the expected outcome and the specific action being tested.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeControllerTest.java (2)
16-27: LGTM! Well-structured test class.The test class follows good testing practices with proper use of Mockito for mocking dependencies and a clean organization using @mock and @Injectmocks annotations.
31-45: LGTM! Clear and descriptive test method name.The renamed method
should_returnWahlvorschlaegeDTO_when_serviceIsCalledfollows the new naming convention and clearly describes:
- Expected outcome: return WahlvorschlaegeDTO
- Condition: when service is called
This improves test readability and aligns with the PR's objective of standardizing test naming conventions.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahltageClientMapperTest.java (2)
22-22: Great improvement in test method naming!The new name
should_returnWahltagModel_when_givenWahltagDTOfollows BDD naming conventions and clearly communicates both the expected outcome and the test conditions. This makes the test's purpose immediately clear without having to read the implementation.
48-48: Excellent consistency in test naming!The new name
should_returnWahltagModelList_when_givenWahltagDTOListmaintains the same clear BDD naming pattern, making it immediately obvious that this test handles the collection mapping scenario.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenValidatorTest.java (3)
32-32: LGTM! Clear and descriptive test method name.The new name
should_notThrowException_when_requestParamIsValidfollows a clear pattern that improves readability by explicitly stating both the expected behavior and the condition under which it occurs.
38-38: LGTM! Clear and descriptive test method name.The new name
should_throwException_when_wahlIDisNullOrEmptyOrBlankfollows a clear pattern that improves readability by explicitly stating both the expected behavior and the condition under which it occurs.
50-50: LGTM! Clear and descriptive test method name.The new name
should_throwException_when_wahlbezirkIDisNullOrEmptyOrBlankfollows a clear pattern that improves readability by explicitly stating both the expected behavior and the condition under which it occurs.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineModelMapperTest.java (3)
5-5: LGTM!The import statement for
UngueltigeWahlscheineis correctly placed and necessary for the test class.
21-21: LGTM! Clear and descriptive test name.The new test name follows the "should_when" pattern and clearly describes the expected outcome and test conditions, making the test's purpose immediately clear.
37-37: LGTM! Clear and descriptive test name.The new test name follows the "should_when" pattern and clearly describes the expected outcome and test conditions, making the test's purpose immediately clear.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahldatenClientImplTest.java (3)
43-44: LGTM! Clear and descriptive test name.The new test name
should_mapClientResponse_when_callingGetfollows the established convention and clearly describes the test's purpose, making it easier to understand what's being verified.
60-61: LGTM! Precise exception handling test name.The new test name
should_throwFachlicheWlsException_when_givenNullclearly specifies the expected exception type and the condition that triggers it.
71-72: LGTM! Well-structured error handling test name.The new test name
should_throwTechnischeWlsException_when_apiInvocationFailedprecisely describes both the expected exception and the failure scenario being tested.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/KopfdatenRepositoryTest.java (1)
39-40: LGTM! Clear and descriptive test name.The new method name follows BDD style naming convention and clearly describes the test's purpose and expected behavior.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerIntegrationTest.java (4)
16-17: LGTM!The new imports for
WahltagandWahltagRepositoryare correctly added and align with their usage in the test methods.
96-96: Test names in GetWahlen class follow the new naming convention.The test method names have been improved to clearly indicate:
- The expected outcome (
should_return...)- The conditions under which the outcome occurs (
when_...)This makes the test's purpose immediately clear and follows the PR's objective of standardizing test naming conventions.
Also applies to: 122-122, 145-145, 166-166
190-190: Test names in PostWahlen class follow the new naming convention.The test method names have been improved to clearly indicate:
- The expected outcome (
should_save...,should_return...)- The conditions under which the outcome occurs (
when_...)This makes the test's purpose immediately clear and follows the PR's objective of standardizing test naming conventions.
Also applies to: 209-209, 235-235, 253-253
272-272: Test name in ResetWahlen class follows the new naming convention.The test method name has been improved to clearly indicate:
- The expected outcome (
should_resetExistingWahlen)- The conditions under which the outcome occurs (
when_wahlenArePresentInRepo)This makes the test's purpose immediately clear and follows the PR's objective of standardizing test naming conventions.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenValidatorTest.java (2)
38-38: LGTM! Test names follow a consistent and descriptive pattern.The renamed test methods follow a clear and consistent naming convention that accurately describes their purpose. The pattern
should_throwException_when_<condition>makes it immediately clear what each test verifies.Also applies to: 46-46, 56-56, 66-66, 76-76
1-91: LGTM! Well-structured test class with good organization.The test class demonstrates good testing practices:
- Uses @nested for logical grouping
- Properly mocks dependencies
- Has helper methods for test data
- Covers both valid and invalid scenarios
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlvorschlaegeClientImplTest.java (2)
42-42: Great improvement in test method naming!The new name
should_mapClientResponse_when_callingGetfollows a clear behavior-driven development pattern that makes the test's purpose immediately clear. This aligns well with the PR's objective of standardizing test naming conventions.
58-58: Excellent test name clarification!The new name
should_throwFachlicheWlsException_when_givenNullis more specific and informative than the original, clearly indicating both the expected exception type and the triggering condition.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeDTOMapperTest.java (2)
22-22: LGTM! Clear and descriptive test name.The renaming from
nullInNullOuttoshould_returnNull_when_givenNullfollows the new naming convention and clearly communicates the test's purpose.
27-27: LGTM! Clear and descriptive test name.The renaming from
isMappedToDTOtoshould_returnWahlvorschlaegeDTO_when_givenWahlvorschlaegeModelfollows the new naming convention and clearly communicates the test's purpose.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SwaggerConfigurationTest.java (1)
37-37: LGTM! Test name now follows the standard convention.The renaming from
versionIsSetInDoctoshould_setVersionInDoc_when_callingApiimproves clarity by explicitly stating the expected outcome and condition. This aligns well with the PR's objective of standardizing test naming conventions.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlModelMapperTest.java (1)
19-19: LGTM! Clear and descriptive test name.The new method name follows the established naming convention and clearly describes the test's purpose and expectations.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/handbuch/HandbuchControllerIntegrationTest.java (6)
56-56: LGTM! Test method names now clearly describe their behavior.The renaming of test methods follows a consistent
should_[expected outcome]_when_[condition]pattern, which makes the test's purpose immediately clear. This aligns well with the PR's objective of standardizing test naming conventions.Also applies to: 73-73, 91-91, 105-105, 122-122
56-70: Test behavior matches the new descriptive name.The test
should_returnData_when_callingGetHandbuchcorrectly verifies:
- The expected outcome: returns data (PDF content)
- The condition: when calling the getHandbuch endpoint
73-83: Test behavior matches the new descriptive name.The test
should_throwInternalServerErrorException_when_noDataIsFoundInRepocorrectly verifies:
- The expected outcome: throws an internal server error
- The condition: when no data exists in the repository
91-102: Test behavior matches the new descriptive name.The test
should_saveData_when_callingSaveHandbuchcorrectly verifies:
- The expected outcome: saves the manual data
- The condition: when calling the saveHandbuch endpoint
105-119: Test behavior matches the new descriptive name.The test
should_replaceData_when_dataIsPresentcorrectly verifies:
- The expected outcome: replaces existing manual data
- The condition: when data is already present in the repository
122-132: Test behavior matches the new descriptive name.The test
should_returnInternalServerErrorException_when_attachmentIsMissingcorrectly verifies:
- The expected outcome: returns an internal server error
- The condition: when the manual attachment is missing from the request
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/KonfigurierterWahltagClientImplTest.java (3)
42-42: LGTM! Clear and descriptive test name.The renamed test method follows the new naming convention and clearly describes both the expected behavior and the condition under which it occurs.
58-58: LGTM! Improved test name specificity.The renamed test method clearly specifies the exact exception type being thrown and the condition that triggers it.
68-68: LGTM! Comprehensive test name.The renamed test method provides clear insight into both the technical exception being thrown and the specific failure condition that triggers it.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltageServiceTest.java (3)
41-41: LGTM! Clear and descriptive test name.The new test name follows the established naming convention and clearly communicates the test's purpose and conditions.
81-81: LGTM! Clear and descriptive test name.The new test name follows the established naming convention and clearly communicates the test's purpose.
94-94: LGTM! Clear and descriptive test name.The new test name follows the established naming convention and clearly communicates the expected exception scenario.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceSecurityTest.java (2)
56-56: LGTM! Clear and descriptive test name.The new method name follows BDD naming convention and clearly describes the test's purpose: verifying that access is granted when required authorities are present.
72-72: LGTM! Clear and descriptive test name.The new method name follows BDD naming convention and clearly describes the parameterized test's purpose: verifying that access is denied when any required authority is missing.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahltag/WahltagModelMapperTest.java (1)
15-16: Great job on the test method renaming!The new method names follow a clear and consistent pattern (
should_[expectedResult]_when_[condition]) that effectively communicates:
- The expected outcome of the test
- The conditions under which the test is performed
This improves code readability and aligns well with the PR's objective of standardizing test naming conventions.
Also applies to: 25-26, 35-36
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenValidatorTest.java (2)
31-31: LGTM! Test method names are now more descriptive and consistent.The renamed test methods clearly communicate:
- The expected outcome ("should_return[No]Exception")
- The test conditions ("when_criteriaIs[Valid|Null|Empty|Blank]")
This improves test readability and aligns with the PR's objective of standardizing test naming conventions.
Also applies to: 36-36, 45-45, 54-54
67-67: LGTM! Test method names follow the established convention.The renamed test methods maintain consistency with the "should_return[No]Exception_when_Y" pattern, clearly describing:
- Valid model scenarios
- Invalid wahltagID scenarios (null, empty, blank)
- Invalid wahlen scenarios (null, empty)
Also applies to: 74-74, 85-85, 96-96, 107-107, 118-118
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineServiceTest.java (1)
42-43: LGTM! Test method names follow the new naming convention.The test method names have been updated to follow a clear and descriptive pattern of
should_[expected outcome]_when_[condition], which aligns with the PR objectives of standardizing test naming conventions. The new names effectively communicate:
- The expected behavior
- The conditions under which the behavior occurs
Also applies to: 61-62, 79-80, 95-96
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenServiceTest.java (3)
48-49: LGTM! Clear and descriptive test name.The renamed test method follows the new naming convention and clearly communicates both the expected behavior (import and save data) and the precondition (no data exists).
71-72: LGTM! Clear and descriptive test name.The renamed test method follows the new naming convention and accurately reflects its purpose of returning existing data without performing an import.
92-93: LGTM! Clear and descriptive test name.The renamed test method follows the new naming convention and effectively communicates the error handling behavior being tested.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/handbuch/HandbuchControllerTest.java (2)
50-50: LGTM! Clear and descriptive test name.The new test name
should_callService_when_callingGetHandbuchclearly describes the test's purpose and follows the established naming convention.
94-94: LGTM! Precise and descriptive test name.The new test name
should_returnTechnischeWlsException_when_ioExceptionIsThrownaccurately describes the exception mapping being tested and follows the established naming convention.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenModelMapperTest.java (5)
23-23: LGTM! Clear and descriptive test method name.The new method name follows BDD naming convention and clearly describes the test's purpose, making it easier to understand the expected behavior.
39-39: LGTM! Consistent test naming pattern.The method name follows the established BDD naming convention and maintains consistency with other test methods.
71-71: LGTM! Well-structured test name.The method name clearly describes the test's purpose while maintaining consistency with the established naming pattern.
98-98: LGTM! Consistent and clear test name.The method name follows the established pattern and clearly communicates the test's purpose.
46-47: LGTM! Improved code formatting.The indentation changes in Set.of() method calls enhance code readability while maintaining consistency throughout the file.
Also applies to: 54-55, 76-77, 87-87
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/referendumvorlagen/ReferendumvorlagenServiceSecurityTest.java (4)
61-61: LGTM! Clear and descriptive test name.The new method name
should_grantAccess_when_authoritiesArePresentfollows BDD naming conventions and clearly communicates the test's purpose.
81-81: LGTM! Clear and descriptive test name.The new method name
should_denyAccess_when_authoritiesAreMissingfollows BDD naming conventions and clearly communicates the test's purpose.
99-99: LGTM! Clear and descriptive test name.The new method name
should_denyAccess_when_oneRepositoryAuthorityIsMissingfollows BDD naming conventions and clearly communicates the test's purpose.
61-99: Great job on standardizing test names!The consistent use of BDD-style naming conventions (
should_[expected outcome]_when_[condition]) across all test methods significantly improves readability and maintainability. This aligns well with the PR's objective of standardizing test naming conventions in the basisdatenservice.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/common/FileMapperTest.java (3)
28-28: LGTM! Clear and descriptive test name.The new method name
should_buildResponseEntity_when_dataIsGivenfollows the established naming convention and clearly communicates the test's purpose and conditions.
48-48: LGTM! Clear and descriptive test name.The new method name
should_getDataFromRequest_when_sendingRequestfollows the established naming convention and clearly communicates the test's purpose and conditions.
61-61: LGTM! Clear and descriptive test name.The new method name
should_returnIoException_when_requestHasNoFilefollows the established naming convention and clearly communicates the test's purpose and conditions.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeValidatorTest.java (4)
31-31: LGTM! The test method name follows the new naming convention.The updated method name clearly describes the expected behavior and test conditions.
37-37: LGTM! The test method name follows the new naming convention.The updated method name clearly describes the expected behavior and test conditions.
45-45: LGTM! The test method name follows the new naming convention.The updated method name clearly describes the expected behavior and test conditions.
53-53: LGTM! The test method name follows the new naming convention.The updated method name clearly describes the expected behavior and test conditions.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlbezirkeClientImplTest.java (4)
44-44: LGTM! Clear and descriptive test name.The new name
should_mapClientResponse_when_callingGetfollows the established naming convention and accurately describes the test's purpose.
61-61: LGTM! Precise exception handling test name.The new name
should_throwFachlicheWlsException_when_clientResponseIsNullclearly indicates both the expected exception type and the triggering condition.
71-71: LGTM! Well-structured error handling test name.The new name
should_throwTechnischeWlsException_when_apiInvocationFailedprecisely describes the technical exception scenario being tested.
1-83: LGTM! Well-organized test class with consistent naming.The test class is well-structured with:
- Clear test organization using @nested classes
- Consistent test naming following the "should_[expected outcome]when[condition]" pattern
- Proper test grouping and separation of concerns
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/nfcconverter/NfcHelperTest.java (2)
1-35: Well-structured test class with clear test data setup!The class follows best practices with proper organization of imports, clear constant definitions, and well-documented test data setup using NFD and NFC character pairs.
37-37: Excellent test naming improvements following BDD style!The renaming of test methods to follow the "should_[expected outcome]when[condition]" pattern significantly improves readability and clarity. The names now clearly communicate:
- The expected behavior
- The test conditions
- The test's purpose
Also applies to: 51-51, 63-63, 69-69, 83-83, 93-93, 105-105, 117-117
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineServiceSecurityTest.java (3)
7-8: LGTM!The reintroduced imports are necessary for the test class functionality and follow standard Java import conventions.
48-48: LGTM! Clear and descriptive test method names.The renamed methods follow a consistent "should_[expected outcome]when[condition]" pattern, making the test's purpose and expectations immediately clear. This aligns well with the PR's objective to standardize test naming conventions.
Also applies to: 63-63
83-83: LGTM! Consistent and descriptive test method names.The renamed methods maintain the same clear "should_[expected outcome]when[condition]" pattern, providing excellent clarity about test expectations and conditions. The naming is consistent across all test methods in the file.
Also applies to: 91-91, 99-99
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlenControllerTest.java (1)
32-33: LGTM! Test name follows the new naming convention.The test name has been updated to follow the descriptive naming convention
should_returnWahlDTOList_when_serviceIsCalled, which clearly indicates the expected outcome and conditions.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchServiceTest.java (6)
5-5: LGTM!The import statement is correctly organized and used within the test class.
45-45: LGTM! Clear and descriptive test name.The new method name follows the standardized naming convention and clearly communicates the test's purpose: it verifies that a Handbuch is returned when data exists in the repository.
60-60: LGTM! Excellent test name for error case.The new method name clearly indicates the expected exception when data is not found, following the standardized naming convention.
78-78: LGTM! Clear test name for successful operation.The new method name effectively communicates that it tests the successful saving of a Handbuch during a POST operation.
91-91: LGTM! Well-named validation error test.The new method name clearly indicates that it tests the validation failure scenario and its expected exception.
104-104: LGTM! Clear exception mapping test name.The new method name effectively communicates the test's purpose of verifying exception mapping behavior during save failures.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/handbuch/HandbuchModelMapperTest.java (3)
5-5: LGTM!The added import for
Handbuchclass is necessary and correctly placed.
23-24: Great improvement in test method naming!The renamed test methods now clearly describe:
- The expected outcome (
should_returnWahltagIdUndWahlbezirksart,should_mapAllWahlbezirksArtEnumValues)- The test conditions (
when_givenHandbuchReferenceModel)This makes the test's purpose immediately clear and aligns well with the new naming conventions.
Also applies to: 34-34
44-44: Excellent test method naming!The renamed test methods follow the same clear pattern:
- The expected outcome (
should_returnHandbuchEntity,should_mapAllWahlbezirksArtEnumValues)- The test conditions (
when_givenHandbuchWriteModel)This maintains consistency with the naming convention throughout the test class.
Also applies to: 55-55
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeValidatorTest.java (1)
31-31: LGTM! Test method names now follow a clear and consistent naming convention.The new method names clearly describe the expected behavior and conditions using the "should_[expected outcome]when[condition]" pattern, making the test's purpose immediately apparent.
Also applies to: 42-42, 49-49, 56-56, 63-63
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineControllerIntegrationTest.java (2)
56-56: LGTM! Test method names are now more descriptive.The renamed test methods in the
GetUngueltigeWahlscheineclass now follow a clear and consistent pattern that better describes the expected behavior and test conditions. This improves code readability and maintainability.Also applies to: 73-73, 86-86
104-104: LGTM! Test method names are now more descriptive.The renamed test methods in the
SetUngueltigeWahlscheineclass now follow a clear and consistent pattern that better describes the expected behavior and test conditions. This improves code readability and maintainability.Also applies to: 118-118, 137-137, 152-152
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/ungueltigewahlscheine/UngueltigeWahlscheineDTOMapperTest.java (1)
25-31: LGTM! Clear and descriptive test name.The new test name effectively communicates the expected behavior and test conditions, aligning with the PR's goal of improving test naming conventions.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlen/WahlDTOMapperTest.java (2)
21-22: LGTM! Clear and descriptive test name.The new name
should_returnNull_when_givenNullfollows the established naming convention and clearly communicates both the expected behavior and test condition.
26-27: LGTM! Descriptive test name that matches the test logic.The new name
should_returnWahlDTOList_when_givenWahlModelListclearly describes the mapping operation being tested and follows the established naming convention.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceTest.java (4)
55-55: LGTM! Clear and descriptive test method name.The new name clearly communicates both the expected behavior (returning repo data and not calling remote client) and the condition (repo data found).
75-75: LGTM! Descriptive test method name.The new name clearly communicates the test's purpose: returning remote client data when repository data is not found.
113-113: LGTM! Clear error case test name.The new name effectively communicates the expected exception and the condition that triggers it.
131-131: LGTM! Clear update scenario test name.The new name effectively communicates the update behavior being tested.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/UserInfoAuthoritiesServiceTest.java (6)
59-59: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
89-89: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
119-119: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
142-142: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
162-162: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
179-179: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows a consistent "should_when" pattern.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlen/WahlenServiceSecurityTest.java (3)
11-12: LGTM!The added imports for
WahltagandWahltagRepositoryare necessary for the test functionality.
66-66: LGTM! Clear and descriptive test method names.The renamed methods in the GetWahlen class follow the
should_action_when_conditionpattern, making the test's purpose immediately clear:
should_grantAccess_when_authoritiesArePresentshould_denyAccess_when_anyAuthorityIsMissingAlso applies to: 78-78
107-107: LGTM! Improved test method naming clarity.The renamed methods in the PostWahlen class clearly indicate the expected behavior and conditions:
should_grantAccess_when_authoritiesArePresentshould_denyAccess_when_serviceAuthorityIsMissingshould_throwTechnischeWlsException_when_repoAuthorityIsMissingAlso applies to: 116-116, 127-127
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/KopfdatenServiceSecurityTest.java (3)
57-57: LGTM! Clear and descriptive test method name.The new name
should_grantAccess_when_authoritiesArePresentclearly communicates the test's purpose and expected behavior, following the established naming convention.
80-80: LGTM! Descriptive name for parameterized test.The new name
should_denyAccess_when_authoritiesAreMissingAndRepoIsEmptyclearly describes both the test condition and expected outcome, making the test's purpose immediately apparent.
108-108: LGTM! Clear distinction in test name.The new name
should_denyAccess_when_authoritiesAreMissingAndRepoIsNotEmptyeffectively distinguishes this test from its empty-repo counterpart while maintaining the naming convention.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahltag/WahltageControllerIntegrationTest.java (5)
84-84: LGTM! Clear and descriptive test name.The renamed test method follows BDD naming conventions and clearly communicates both the expected outcome and the test condition.
106-106: LGTM! Descriptive test name that reflects persistence verification.The renamed test method clearly indicates its purpose of verifying data persistence while following consistent naming conventions.
129-129: LGTM! Clear test name for complex flow.The renamed test method effectively describes the multi-step process while maintaining consistent naming conventions.
162-162: LGTM! Clear error case test name.The renamed test method effectively communicates the expected exception and the condition that triggers it.
83-162: Excellent test naming improvements across the class.The systematic renaming of test methods to follow the
should_[expected result]_when_[condition]pattern significantly improves test readability and documentation. This aligns perfectly with the PR's objective of standardizing test naming conventions.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahlRepositoryTest.java (5)
43-44: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows the established naming convention.
59-60: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows the established naming convention.
70-71: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows the established naming convention.
82-83: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows the established naming convention.
94-95: LGTM! Clear and descriptive test name.The new name accurately describes the test's purpose and follows the established naming convention.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlbezirke/WahlbezirkeServiceTest.java (2)
4-4: LGTM!The import statement is correctly placed and necessary for the test implementation.
48-48: Great improvement in test method naming!The renamed test methods follow a clear
should_[expectedBehavior]_when_[condition]pattern, making the test's purpose and expectations more explicit. This aligns well with the PR's objective of standardizing test naming conventions.Also applies to: 76-76
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/domain/WahlbezirkRepositoryTest.java (4)
39-39: LGTM! The test method names now clearly describe their purpose.The renaming follows a consistent and descriptive pattern that makes it immediately clear what each test verifies:
- Expected outcome is clearly stated (e.g.,
returnWahlbezirkList,returnTrue,deleteWahltag)- Test conditions are well-defined (e.g.,
when_findByWahltagIsCalled,when_oneWahltagExistsInRepo)This improves test readability and maintenance.
Also applies to: 53-53, 63-63, 74-74, 85-85
38-47: The test name accurately reflects its implementation.The name
should_returnWahlbezirkList_when_findByWahltagIsCalledperfectly matches what the test verifies:
- It checks if a list is returned (
returnWahlbezirkList)- The condition is calling
findByWahltag(when_findByWahltagIsCalled)
49-82: The nested test class method names clearly distinguish different scenarios.The three test methods in
ExistsByWahltagare well-named to cover distinct cases:
- Single existence check
- Multiple existence check
- Non-existence check
Each name accurately describes its test scenario and expected outcome.
84-97: The test name accurately reflects the deletion verification.The name
should_deleteWahltag_when_callingDeleteclearly describes:
- The expected action (
deleteWahltag)- The trigger condition (
when_callingDelete)The implementation confirms this by verifying that only the non-deleted wahltag's data remains.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/wahlvorschlag/WahlvorschlaegeControllerIntegrationTest.java (2)
94-94: Great job on improving test method names!The renamed test methods now follow a clear and descriptive naming convention that makes it easier to understand:
- The expected outcome of each test
- The conditions under which the test is performed
This improves code readability and helps in quickly identifying test failures.
Also applies to: 115-115, 139-139, 163-163
90-180: Well-structured and comprehensive test implementation!The test class demonstrates several good practices:
- Organized test scenarios using
@Nested- Proper mocking of external services with WireMock
- Clear arrange/act/assert phases
- Comprehensive assertions using AssertJ
- Proper cleanup with
@AfterEach- Transaction management for database operations
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/WahlenClientMapperTest.java (2)
55-55: LGTM! Clear and descriptive test name.The new method name
should_returnWahlModelList_when_wahlDTOList()clearly describes the test's purpose and expected behavior, following the "should_[expected outcome]when[condition]" pattern.
24-24: LGTM! Clear and descriptive test name.The new method name
should_returnWahlModel_when_givenWahlDTO()clearly describes the test's purpose and expected behavior, following the "should_[expected outcome]when[condition]" pattern.Let's verify this follows the project's naming convention guidelines:
❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Check for naming convention documentation and other similarly named tests fd -t f "README.md" -X grep -l "test.*naming.*convention" ast-grep --pattern 'void should_return$_when_given$_'Length of output: 113
LGTM! Clear and descriptive test name.
The new test name
should_returnWahlModel_when_givenWahlDTO()accurately describes the expected behavior using the "should_[expected outcome]when[condition]" format, which is a widely accepted naming pattern for tests. Although our scripted search did not reveal explicit documentation or a central guideline in the repository regarding test naming conventions, the change aligns with similar renamings in this PR.Please manually verify that this naming approach is consistent with any internal standards your team may follow.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/kopfdaten/BasisdatenValidatorTest.java (6)
38-38: LGTM! Clear and descriptive test name.The new method name
should_notThrowException_when_basisdatenContentIsValidclearly communicates both the expected behavior and the test condition.
44-44: LGTM! Improved clarity and fixed typo.The new method name
should_throwException_when_notEveryPropertyContainsDatafollows the convention and fixes the typo in "Contains".
130-130: LGTM! Improved naming clarity.The new method name clearly describes the validation of relationships between Wahl and its dependencies while following the naming convention.
151-151: LGTM! Clear validation purpose.The new method name effectively communicates the validation of relationships between Wahlbezirk and its dependencies.
172-172: LGTM! Consistent naming pattern.The new method name maintains consistency with the established naming pattern while clearly describing the validation purpose.
32-191: LGTM! Well-organized test structure.The test class is well-organized with:
- Logical grouping of tests using nested class
- Comprehensive coverage of validation scenarios
- Consistent use of the new naming convention
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/clients/DummyClientImplTest.java (4)
16-25: LGTM! Clear and descriptive test method name.The renamed test method now clearly communicates both the expected outcome and the test conditions.
27-35: LGTM! Test name now reflects the business rule.The renamed test method clearly communicates the business rule about the three-month time window.
37-45: LGTM! Test name now clearly states the expectation.The renamed test method clearly communicates the expected minimum size of the result.
47-94: LGTM! Test names now clearly describe data relationships.The renamed test methods effectively communicate the expected relationships between different entities in the basisdaten.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceTest.java (3)
43-43: LGTM! Clear and descriptive test name.The new name
should_loadAndStoreData_when_serviceIsCalledclearly communicates the test's purpose and follows good test naming conventions.
82-82: LGTM! Test name clearly differentiates from the previous test.The new name
should_loadExistingData_when_serviceIsCalledeffectively communicates that this test handles the existing data scenario, distinguishing it from the missing data case.
113-113: LGTM! Test name accurately reflects the exception handling.The new name
should_throwRuntimeException_when_clientFailedprecisely describes both the expected outcome and the triggering condition.wls-basisdaten-service/pom.xml (1)
536-537: LGTM!The formatting improvements in the Spotless plugin configuration enhance XML consistency.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/rest/referendumvorlagen/ReferendumvorlagenControllerIntegrationTest.java (1)
90-90: LGTM! Test method names follow clear naming convention.The renamed test methods follow a consistent and descriptive pattern
should_[expectedOutcome]_when_[condition]which clearly communicates:
- The expected outcome of the test
- The conditions under which the test is performed
Let's verify that this naming convention is consistently applied across other test classes:
Also applies to: 130-130, 144-144, 162-162
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Check if other test methods follow the same naming convention # Pattern: should_*_when_* rg -t java "void\s+should_\w+_when_\w+" "src/test"Length of output: 99
I'll verify the naming convention across test files by searching in the correct test directory. In our repository, tests are located under
wls-basisdaten-service/src/test/java. Let's run a shell script to search for test methods matching the patternvoid should_*_when_*in that directory.
🏁 Script executed:
#!/bin/bash echo "Searching for test method names following the naming convention in wls-basisdaten-service/src/test/java:" rg -t java "void\s+should_\w+_when_\w+" wls-basisdaten-service/src/test/javaLength of output: 76711
LGTM! Consistent Naming Convention Verified Across Test Classes
The test method names now follow the clear and descriptive pattern (
should_[expectedOutcome]_when_[condition]) that we see consistently throughout the codebase. In particular, the renamed test inReferendumvorlagenControllerIntegrationTest.javaaligns perfectly with similar conventions applied in other test classes.wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/services/ungueltigewahlscheine/UngueltigeWahlscheineValidatorTest.java (2)
32-32: LGTM! Test method names now follow a clear and consistent pattern.The renaming of test methods to follow the "should_returnX_when_Y" pattern improves readability and makes test failures more understandable. The new names clearly communicate:
- The expected outcome (e.g., "returnNoException", "returnException")
- The test conditions (e.g., "modelIsValid", "wahltagIDIsNull")
Also applies to: 39-39, 47-47, 58-58, 68-68, 78-78
1-183: Verify compliance with ArchUnit test naming conventions.The test method names have been successfully updated to follow a consistent "should_returnX_when_Y" pattern. To ensure these changes meet the architectural requirements:
- Verify that the naming pattern matches the ArchUnit rules
- Confirm that similar naming conventions are applied across all test classes
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Check if all test methods follow the naming convention # Search for test methods that don't follow the pattern echo "Test methods that might not follow the convention:" rg "void\s+(?!should_\w+_when_\w+)\w+\s*\(\s*\)\s*{" -g "**/*Test.java" # Count total test methods vs non-compliant ones echo -e "\nTest method naming statistics:" echo "Total test methods:" rg -c "@Test" -g "**/*Test.java" | awk -F: '{sum += $2} END {print sum}' echo "Non-compliant test methods:" rg -c "void\s+(?!should_\w+_when_\w+)\w+\s*\(\s*\)\s*{" -g "**/*Test.java" | awk -F: '{sum += $2} END {print sum}'Length of output: 1087
I'll rerun the verification using the PCRE2 flag (which supports look-around) to correctly check the naming convention. Please run the following script and share its output:
🏁 Script executed:
#!/bin/bash # Using PCRE2 regex to search for test methods not following the naming convention. echo "Test methods that might not follow the naming convention (PCRE2 enabled):" rg --pcre2 "void\s+(?!should_\w+_when_\w+)\w+\s*\(\s*\)\s*{" -g "**/*Test.java" echo -e "\nTest method naming statistics:" echo "Total test methods:" rg -c "@Test" -g "**/*Test.java" | awk -F: '{sum += $2} END {print sum}' echo "Non-compliant test methods:" rg --pcre2 -c "void\s+(?!should_\w+_when_\w+)\w+\s*\(\s*\)\s*{" -g "**/*Test.java" | awk -F: '{sum += $2} END {print sum}'Length of output: 65916
Test Naming Conventions Adherence Confirmed in UngueltigeWahlscheineValidatorTest.java
The test methods in this file consistently use the “should_returnX_when_Y” pattern in both nested classes. This aligns with the ArchUnit rules specified in the PR objectives. While our broader search also revealed non-compliant names in other test files (e.g. lifecycle methods like “setUp” or “tearDown”), those are generally exempt from the naming convention requirements. The changes in this file meet the architectural naming guidelines.
wls-basisdaten-service/src/test/java/de/muenchen/oss/wahllokalsystem/basisdatenservice/configuration/SecurityConfigurationTest.java (2)
58-98: LGTM! Core security tests are well-structured.The renaming of core security test methods follows a clear and descriptive pattern that effectively communicates the test's purpose and expected behavior. The tests cover essential endpoints including root access, actuator endpoints, API docs, and Swagger UI.
31-56: LGTM! Test configuration and dependencies are properly set up.The test class is well-configured with necessary annotations and dependencies:
- Uses
@SpringBootTestwith MOCK environment- Configures MockMvc and Observability
- Mocks all required services
...s/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeValidatorTest.java
Outdated
Show resolved
Hide resolved
...oss/wahllokalsystem/basisdatenservice/services/wahlvorschlag/WahlvorschlaegeServiceTest.java
Outdated
Show resolved
Hide resolved
|
Ticket für die Umsetzung von Tests für CSRF-Coverage (siehe CodeRabbit) erledigt mit #812 |
|
@GerhardPx Please Update Branch |
Co-authored-by: Nic12345678 <[email protected]>
Beschreibung:
ArchUnitTest für Test namings in basisdatenservice eingeführt
alle Tests im basisdatenservice entsprechend angepasst
Definition of Done (DoD):
Backend
[ ] Doku aktualisiert[ ] Swagger-API vollständig[ ] Unit-Tests gepflegt[ ] Integrationstests gepflegt[ ] Beispiel-Requests gepflegtDokumentation
[ ] Links geprüftReferenzen[^1]:
Closes #429
Summary by CodeRabbit
Chore
Tests / Refactor
These internal enhancements bolster overall code quality without impacting existing functionality for end-users.