Il modo migliore per testare un servizio web reimplementato

Bene, dopo esserci immersi profondamente in questo, abbiamo due possibili soluzioni:

• Riproduci i dati dei prodotti: sarà un po 'complicato farlo, ma la cosa buona è che se riesci a catturare e riprodurre i dati del prodotto sul tuo servizio, allora tutto il test di integrazione di whitebox sarà fatto per te. la cosa brutta è che stai solo testando gli input e gli output e non come i dati vengono cambiati dal servizio.
• Un approccio diverso è il seguente: Applicare lo schema di fabbrica per entrambi i client del servizio, quello vecchio e quello nuovo, quindi creare un test per il vecchio servizio (qui si desidera controllare gli oggetti risultato e le modifiche dei dati), migrare il servizio , prova il tuo nuovo servizio contro il test del vecchio.

puoi scrivere approvaltests disponibili per .net e java.

l'idea di implementare un client di prova che chiama il vecchio servizio con valori di input tipici e registra l'output corrispondente dal servizio.

quindi esegui il client di prova contro il nuovo servizio: lo strumento di test di approvazione si lamenta se l'output è diverso dall'uscita registrata in precedenza.

Se non ci sono test per il vecchio servizio, e presumo che tu non voglia sprecare tempo a crearne uno ... allora devi crearne uno, ma uno funzionerà ancora con il nuovo servizio.

Consiglierei selenio e / o cetriolo (o equivalente) mentre lo stai reimplementando, questi guidano il sito web generale da un PoV esterno e registrano i risultati che ottieni. Questo tipo di test di integrazione è molto meno complicato rispetto all'aggiunta di unit test al codice esistente e fornirà una serie di requisiti per il nuovo servizio. Una volta che hai ottenuto alcuni test per il sito web, puoi ripeterlo, quindi puoi sostituirlo e vedere se funziona ancora.

Ho lavorato a una reimplementazione di un grande progetto IT che ha affrontato questa sfida esatta.

Ci sono diversi problemi che potresti incontrare.

• L'implementazione originale avrà app client esistenti che potrebbero essere riluttanti a modificare i loro programmi client e ripetere il test per adattarsi a eventuali modifiche.
• Le specifiche di implementazione originali potrebbero non riflettere l'implementazione originale. Qual è l'obiettivo per la sostituzione?
• L'implementazione originale ha probabilmente dei bug. È probabile che le app client siano state programmate per accettare i bug come 'funzionalità' Risolvi i bug e interrompi le app client.

Se l'obiettivo è un rimpiazzo diretto e di sostituzione, è necessario creare test di riproduzione che portino messaggi di test e la loro risposta dalla versione 1 e creare test di integrazione che trasferiscano questi messaggi nella versione 2 e eseguano diff sul uscita.

Alcune differenze saranno accettabili. Data e ora, numeri di versione, ID di alcuni ecc. Ma identificherai molti bug in questo modo molto prima che le tue app client si avvicinino al sistema riscritto. Alcuni strumenti automatici possono aiutare se il tuo servizio è abbastanza semplice, ma suppongo che finirai con lo scripting della tua suite di test.

Quello che hai descritto è in pratica esattamente ciò che Unit Testing può fornire per te quando esegui un grande refactoring o, nel tuo caso, un'intera riscrittura.

Dovrai prestare particolare attenzione per assicurarti che la tua interfaccia non cambi affatto, in quanto avrai clienti esistenti, e potrebbe valere anche la possibilità di avere un test di integrazione completo.