Suggerimenti per il test dell'applicazione legacy ad alta intensità di dati

Question

Sto lavorando a un'applicazione legacy molto ampia e ad alta intensità di dati. Sia la base di codice che amp; il database ha dimensioni enormi. Gran parte della logica aziendale è diffusa in tutti i livelli, anche nelle procedure memorizzate.

Qualcuno ha qualche suggerimento su come iniziare ad applicare " unit " test (tecnicamente test di integrazione perché hanno bisogno di testare su più livelli per un singolo aspetto di quasi ogni dato processo) nell'applicazione in modo efficiente? L'architettura attuale non supporta facilmente alcun tipo di iniezione o derisione. È stato scritto un nuovo codice per facilitare i test, ma per quanto riguarda il codice legacy? A causa della forte dipendenza dai dati stessi e dalla logica aziendale nel database, sto attualmente usando sql in linea per trovare dati da utilizzare per i test, ma questi richiedono molto tempo. La creazione di viste e / o procedure memorizzate non sarà sufficiente.

Quali approcci hai adottato (se applicabile)? Che cosa ha funzionato? Cosa non & amp; perché? Tutti i suggerimenti sarebbero apprezzati. Grazie.

Answer 1

Ottieni una copia di Lavorare in modo efficace con il codice legacy di Michael Feathers. È pieno di consigli utili per lavorare con codebase di grandi dimensioni non testate.

Un altro buon libro è Pattern di reingegnerizzazione orientata agli oggetti . La maggior parte del libro non è specifica per software orientato agli oggetti. Il testo completo è disponibile per il download gratuito in formato PDF.

Dalla mia esperienza: prova a ...

• Automatizza la compilazione e la distribuzione
• Porta lo schema del database nel controllo versione, se non lo è ancora. Di solito i database includono dati di riferimento che il codice transazionale deve esistere prima che possa funzionare. Prendi anche questo sotto controllo di versione. Strumenti come dbdeploy possono aiutarti a ricostruire facilmente uno schema e i dati di riferimento da una sequenza di delta.
• Installa una versione del database (e di qualsiasi altro servizio di infrastruttura) sulla tua workstation di sviluppo. Ciò ti consentirà di lavorare sul database senza dover continuamente passare attraverso i DBA. È anche più veloce dell'utilizzo di uno schema su un server condiviso in un datacenter remoto. Tutti i principali server di database commerciali hanno versioni di sviluppo gratuite (come nella birra) che funzionano su Windows (se sei bloccato nella situazione non invidiabile di sviluppo su Windows e distribuzione su Unix).
• Prima di iniziare a lavorare su un'area del codice, scrivi dei test end-to-end che coprono approssimativamente il comportamento dell'area su cui stai lavorando. Un test end-to-end dovrebbe esercitare il sistema dall'esterno, controllando la sua interfaccia utente o interagendo attraverso i servizi di rete, quindi non sarà necessario modificare il codice per metterlo in atto. Funzionerà come un test di regressione (imperfetto) e ti darà più fiducia nel refactoring degli interni del sistema verso una struttura più facile da testare.
• Se ci sono piani di test manuali, leggili e vedi cosa può essere automatizzato. La maggior parte dei piani di test manuali è quasi interamente scritta, così come i frutti a bassa pendenza per l'automazione
• Una volta ottenuta la copertura dei test end-to-end, trasforma il codice in unità più liberamente accoppiate mentre lo modifichi e / o estendi. Circonda quelle unità con test unitari.

Cose da evitare:

• Copia dei dati dal database di produzione nell'ambiente utilizzato per i test automatizzati. Questo renderà i tuoi test imprevedibili. Certo, esegui il sistema contro una copia dei dati di produzione, ma usalo per i test esplorativi, non per i test di regressione.
• Ripristino delle transazioni alla fine dei test per isolare i test gli uni dagli altri. Ciò non verificherà il comportamento che si verifica solo quando vengono impegnate le transazioni e eliminerà i dati utili per la diagnosi degli errori del test. Al contrario, i test dovrebbero garantire che il database si trovi in ??uno stato iniziale noto all'avvio.
• Creazione di un " tiny " set di dati per l'esecuzione dei test. Questo rende i test difficili da capire perché non possono essere letti come una singola unità. Il "piccolo" presto il set di dati diventa molto grande quando si aggiungono test per diversi scenari. Al contrario, i test possono inserire dati nel database per configurare l'apparecchiatura di test.

Answer 2

& # 8220; Test della modernizzazione delle applicazioni legacy, & # 8221; In evidenza:

1. Panoramica di alto livello su come vengono creati i test in AscentialTest

2. Modi per convertire gli oggetti legacy nella nuova piattaforma Componenti della definizione degli oggetti

3. Come garantire che la versione modernizzata dell'applicazione produca gli stessi risultati

Per maggiori dettagli sull'uso dell'applicazione di test legacy, controllare qui:

http: // application-management .cioreview.com / whitepaper / test-legacy-application-modernizzazione-wid-529.html