Esiste un punto nell'unità che testa un servizio client che semplicemente passa attraverso i dati dal server? [duplicare]

Prima di ottenere la risposta che stai cercando, devi decidere dove si trova la tua azienda nello spettro dei test:

• All'estrema destra c'è qualcosa come Test Driven Development, che dice che per ogni riga di codice che scrivi, devi avere un test fallito che qualche modifica o nuova linea di codice possa risolvere.
• Da qualche parte nel mezzo ci sono altre scuole di pensiero, trattano il codice come una scatola nera e testano solo il valore che viene fuori.
• All'estrema sinistra non hai test, o test sparsi.

A parte questo, quello che stai parlando di testing è un confine, qualcosa tra il tuo codice e qualcun altro (Web Server, Database, ecc.).

Chiediti, sarebbe utile avere test per il codice che riceve un modello (JSON?) proveniente dal server web e tradurlo in un modello di dati con cui puoi lavorare più facilmente (un modello JavaScript o POJO?)? Per me sarebbe un po 'prezioso, ma non importante come testare i miei strati interni (DataLayer, NetworkLayer, Business Logic, ecc.). E quali sono i costi per mantenere quei test. Anche nei miei posti di lavoro TDD più intransigenti, avevamo dei limiti in merito al fatto che abbiamo fatto poco o nessun test oltre.

Una delle grandi cose dei test ben scritti è che ti aiutano a trovare rapidamente ciò che sta causando un crash o un bug. Tuttavia, qualcosa che si avvicina a un confine, se il codice è SOLIDO, potrebbe già essere facile trovare il problema; probabilmente si interromperà solo quando il codice di terze parti ha cambiato il JSON in uscita, non all'interno del codice. Quindi per me un test non sarebbe meritato

Due pensieri in chiusura:

Non hai bisogno di TDD / test per avere una buona architettura, ma un buon TDD & i test assicurano (impongono) una buona architettura.

I test sui confini spesso diventano complicati e difficili da mantenere. In generale ci siamo concentrati sulla scrittura di buoni test sui livelli interni (DataLayer, NetworkLayer, Business Logic, ecc.).

Sì.

In questo caso, assicurati semplicemente che il servizio web restituisca tutti i dati forniti dalla simulazione.

C'è un valore in questo, anche se sembra banale o noioso. Cosa succede se qualcuno aggiunge in seguito la logica che modifica i dati? Boom: test fallito. Ora hai una discussione sulla necessità di aggiornare il servizio web o il test di unità. Questo è meglio della risoluzione dei problemi relativi ai dati in un ambiente di produzione, e forse non guardi il servizio web "perché restituisce i dati letteralmente". Fino a quando non lo fa.

I test dovrebbero quindi essere relativamente facili da scrivere. Tuttavia, attraverso il processo di scrittura dei test, spesso scopri che non è così banale come pensavi. Ci sono spesso condizioni di confine o di gara che ti mancano che vengono in superficie durante la scrittura di test automatici, condizioni che sono davvero difficili da colpire in un ambiente di produzione.

Inoltre, se si finisce lentamente aggiungendo funzionalità a questa libreria, come è inevitabile, arriverà un punto in cui improvvisamente capirai che ti piacerebbe davvero testare le unità, e sarà difficile aggiungerle allora. Farlo dall'inizio è vicino a zero, alcuni dicono addirittura negativo, costo marginale.

Dì che mi hai appena assunto. Supponiamo che aggiorni 5 cose diverse contemporaneamente. Ora qualcosa è rotto. Capita di essere questo servizio di riposo AngularJS. Ma non lo sappiamo. Quale test potresti aver scritto in passato per aiutarci a diagnosticare il problema oggi?

Puoi prendere in giro il tuo endpoint REST. Qualcosa di stabile che dà al servizio qualcosa di cui parlare che produce risposte prevedibili.

Verifica i casi limite. Cosa succede se i dati restituiti sono enormi? Vuoto? In qualche modo è confuso? Non ritorna mai?

Non riuscire a testare ogni punto in cui le ipotesi che stai facendo potrebbero essere errate è come accadono cose come i bug di sicurezza del buffer overrun.

Vorrei cercare casi limite in cui il tuo sistema non riesce a "passare semplicemente" i dati. Ad esempio, avevamo un tale sistema che funzionava fino a quando non riceveva un valore che poteva essere espresso come un numero intero senza segno a 32 bit, ma se scritto in decimale e letto da un programma Java (dove tutti gli interi sono firmati), non è riuscito.

Il sistema gestisce i valori null correttamente? Fallisce con grazia se una connessione si interrompe? Ecc.