Sto costruendo un'API REST basata sulla posizione utilizzando Spring Boot, e ho incontrato una piccola domanda di filosofia di testing. Ho un oggetto chiamato Location che, tra le altre cose, richiede un ID di Google Places per funzionare. Ho esposto il CRUD di questa risorsa a /locations che delega il suo lavoro a LocationService.createLocation .
Questa classe genera eccezioni se 1). il GooglePlacesId non esiste o 2). se non è valido (non riconosciuto su google places) o 3). il placeId esiste già sul% co_de salvato. Location è una dipendenza di GooglePlacesService e gestisce la comunicazione con l'API di Google. Spring Boot consente di testare la tua API REST direttamente con un server web simulato e un contenitore con LocationService . Quando eseguo il test dell'API di localizzazione, eseguo il mock out di googleService per consentirmi di eseguire il test 2, mentre l'1 e il 3 sono semplici da testare con il seeding del database o l'elaborazione del payload.
Quindi ecco dove sono a un bivio. C'è un altro oggetto MockMvc a cui una Location ha una relazione uno a molti. Una posizione non dovrebbe esistere se non ha post. Quindi, se sto creando un post per un Post che non esiste e utilizzo il Location endpoint per creare il percorso, non sono in grado di creare a livello transazionale la posizione con il post. Ciò risulterebbe in una complessa gestione degli errori dei client e nella pulizia degli oggetti o in una sorta di attività in esecuzione che pulisce le posizioni create con successivi errori di creazione del post. Consiglieresti di utilizzare questo approccio invece di consentire la creazione di oggetti nidificati?
L'alternativa che ho scelto è quella di consentire la creazione di una posizione tramite l'endpoint /locations . Questo endpoint delega a /posts per la creazione della posizione incorporata prima di creare il post. Ciò fornisce la necessaria transazionalità e semplifica il codice client. Hai rotto una separazione di preoccupazioni qui?
Mentre sto testando questo endpoint, i criteri 1-3 si applicano ancora alla creazione di Location nidificate. Qual è il miglior approccio di test: prendi in giro il LocationService.createLocation qui e assicurati semplicemente che questo endpoint gestisca correttamente tutte le eccezioni generate o che realizzi effettivamente i payload come nel test dell'endpoint LocationService e creando veri test di integrazione? Il secondo sembra più lavoro e duplicazione dei test. Allo stesso tempo, i criteri 1-3 sono anche tutti i criteri di questo endpoint e creando veri test per loro, sto assicurando che questi requisiti siano codificati in questo test. Inoltre, non sto correggendo il mio test all'implementazione specifica del /locations che accade ora di usare PostService .
Non è sicuramente in bianco e nero, ma sono sicuro che ci sono alcuni argomenti convincenti per una direzione