Come e dove testare se gli oggetti di richiesta JSON generati dal front-end sono validi

I test di questo tipo hanno due parti distinte: inserire dati controllati, ripetibili e conosciuti su un lato del tubo e tirarlo fuori dall'altro; e convalidare che i dati che hai ottenuto dall'altra parte sono i dati giusti.

Nel contesto di questo ambiente, ciò significa generare dati fittizi che vengono alimentati attraverso l'applicazione e farla uscire dall'altra parte. La convalida dei dati viene quindi eseguita con qualcosa come jsonpath che può convalidare che i dati siano formattati correttamente e contiene le informazioni corrette.

Il punto chiave è prendere i dati conosciuti attraverso il sistema e testarli. Questo non è dati live da un database, o anche da un database. Piuttosto si tratta di dati che sono noti per testare le condizioni marginali del software.

Dato lo sviluppo parallelo:

• Front end (interfaccia utente / browser / javascript) per comportamento e correttezza dei dati possono e devono essere testati. Per sostenere che è possibile sviluppare o riutilizzare framework / strumenti esistenti per supportare il comportamento dell'interfaccia utente (clic e risultati attesi), il contenuto dell'interfaccia utente per la convalida delle lunghezze del campo, alpha vs. num, ecc. E infine la stub (anche noto come mocking) chiamate esterne al back-end pianificato ma non ancora integrato
• Back-end (specifica lingua / piattaforma) avrai bisogno di qualcosa che spinga i dati forzati e la scala del volume previsto all'API REST. Per il testing delle unità a livello di codice esiste una grande quantità di strumenti, ma conoscere la lingua sarà utile.
• Test di integrazione : si tratta del test end-to-end quando si rimuovono gli stub tra il front-end e il back-end. Potresti automatizzarlo con strumenti che supportano feed di dati forzati (o algoritmi).
• Test di prova : qui possono entrare in gioco i dati del mondo reale. A seconda dei problemi di sensibilità / esposizione con il contenuto dei dati, potrebbe essere necessario "scrubare" i dati prima del test.

Per quanto riguarda l'identificazione della causa della radice dell'errore, questo può essere alquanto sfocato, ma di solito si impiega uno schema di classificazione nelle opere di alto livello. Ad esempio:

• UI Core - Errori / Eccezioni associati al layout, alla progettazione, ai comportamenti di controllo o alla logica esistenti solo nelle tecnologie browser / javascript / browser
• UI I / O - Errori / Eccezioni associati alla generazione, all'eccezione di chiamata o all'elaborazione della ricezione dei contenuti
• I / O back-end - Errori / Eccezioni nella gestione iniziale, formattazione, preparazione dei messaggi in arrivo nel punto dell'API REST
• Backend Core - Errori / Eccezioni nei componenti di elaborazione principali dei servizi

Se tutto ciò è nuovo, suggerirei di mantenerlo il più semplice possibile e lasciare che sia necessario guidare l'estensione del modello. Naturalmente questo può significare qualche rielaborazione dei sistemi di categorizzazione e raccolta (JIRA?) Ma l'analisi costi / benefici dipende da te.

Se la tua domanda riguarda come far rispettare "entrambi i livelli" (frontend e backend) usando lo stesso JSON, puoi provare a usare json- schema convalida.

È impossibile catturare tutti i bug, e ovviamente lo schema non copre tutto e presenta dei limiti, ma puoi almeno assicurarti che entrambi i livelli concordino sulla formattazione di JSON. Utilizzando uno schema puoi specificare quali campi sono previsti, quali sono opzionali, i loro tipi, ecc.

Per risolvere i problemi, puoi utilizzare i validatori di schemi online ( qui è uno , ma ce ne sono altri) per vedere se il tuo frontend sta producendo json conformi.

Hai preso in considerazione l'utilizzo di XML piuttosto che JSON? XML ha diverse soluzioni robuste e mature per la convalida, ad es. Schemi XML. JSON è generalmente considerato l'alternativa semplice e leggera all'XML, ma è più semplice se non ha bisogno delle funzionalità più avanzate di XML, come la validazione.

Con uno schema XML è possibile convalidare la richiesta e la risposta XML su entrambi i lati del filo e ciò semplifica l'identificazione di dove ha origine un errore.