Repository navigation
Fissa con un test il presupposto di nullabilità di RicevutaJsonValidator - #113
Merged
Merged
Conversation
…ator Il validator esiste perche' i campi "required" dello schema BizEvents assenti dal JSON caricato arrivano a null sull'oggetto deserializzato: il generatore OpenAPI li annota @jakarta.annotation.Nonnull e vi mette @JsonProperty(required = true), ma per Jackson sono metadati di schema, non vincoli di deserializzazione. Finora quel presupposto era verificato solo di rimbalzo, dal percorso completo di caricamento (RicevutaUploadIntegrationTest. jsonConCampiMancantiRitorna400ChiElencaICampi). Se un aggiornamento di Jackson lo cambiasse, il sintomo sarebbe un caricamento RT che fallisce in modo strano, e la causa andrebbe ricostruita. Qui invece il fallimento punta dritto al punto. Occasione: la migrazione a Jackson 3 (#109), che ha rigenerato anche il client bizevents con useJackson3. Verificato che non cambia nulla: stesse annotazioni sul model (52 @nonnull, 26 required), e i campi obbligatori assenti continuano ad arrivare a null senza che la deserializzazione fallisca. Il test copre anche l'eccezione alla regola: il generatore inizializza le liste, quindi transferList assente arriva vuota e non nulla, ed e' il motivo per cui il validator la verifica con "nulla o vuota". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Perché
RicevutaJsonValidatoresiste perché i campirequireddello schema BizEvents assenti dal JSON caricato arrivano anullsull'oggetto deserializzato: il generatore OpenAPI li annota@jakarta.annotation.Nonnulle vi mette@JsonProperty(required = true), ma per Jackson sono metadati di schema, non vincoli di deserializzazione. È questo che lascia al validator il compito di intercettarli e rispondere con un 400 che li elenca, invece di un errore di parsing opaco.Finora quel presupposto era verificato solo di rimbalzo, dal percorso completo di caricamento (
RicevutaUploadIntegrationTest.jsonConCampiMancantiRitorna400ChiElencaICampi). Se un aggiornamento di Jackson lo cambiasse, il sintomo sarebbe un caricamento RT che fallisce in modo strano e la causa andrebbe ricostruita da capo. Questo test fa fallire la build nel punto esatto, dicendo cosa è cambiato.Occasione
La migrazione a Jackson 3 (#109), che ha aggiunto
useJackson3anche all'esecuzione del generatore per il client bizevents. Ho verificato che non cambia nulla di rilevante:@Nonnull, 26required = true,getDebtor/getPaymentAmount/getTransferList@Nonnull,getPayer@Nullable);com.fasterxml.jackson.annotation— non è migrazione incompleta, Jackson 3 ha lasciato lì di proposito le annotazioni, spostando solodatabindecoresottotools.jackson;{"receiptId":"RT1"}i campi obbligatori arrivano anullsenza alcuna eccezione.Nessuna modifica al codice di produzione è risultata necessaria.
Cosa copre
campiRequiredAssentiNonFannoFallireLaDeserializzazionecampiRequiredAssentiRestanoNullNonostanteLAnnotazioneNonnull@NonnullarrivanonulltransferListAssenteArrivaVuotaNonNullailValidatorIntercettaQuellAssenzaL'eccezione alla regola: il generatore inizializza le liste (
= new ArrayList<>()), quinditransferListassente arriva vuota e non nulla. È il motivo per cui il validator la verifica con "nulla o vuota": controllare solo la nullità lascerebbe passare una ricevuta senza alcun trasferimento. Era un dettaglio implicito, ora è scritto.Verifica
Ho controllato che l'asserzione del quarto test non fosse vacua, inserendo temporaneamente un campo inesistente fra quelli attesi nel messaggio: il test fallisce come deve.
Suite completa: 1402 test, 0 failures, 0 errors.
🤖 Generated with Claude Code