Suggerimenti per testare l'applicazione legacy intensiva di dati

Question

Sto lavorando su un'applicazione legacy di grandi dimensioni e ad alta intensità di dati. Entrambi i database di base & sono di dimensioni enormi. Gran parte della logica di business si sviluppa su tutti i livelli, incluse le stored procedure.

Qualcuno ha qualche suggerimento su come iniziare ad applicare i test di "unità" (tecnicamente test di integrazione perché devono testare su più livelli per un singolo aspetto di quasi tutti i processi) 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 utilizzando sql in linea per trovare i dati da utilizzare per il test, ma questi richiedono molto tempo. La creazione di viste e/o stored procedure non è sufficiente.

Quali approcci avete adottato (se applicabile)? Cosa ha funzionato? Cosa non ha fatto & perché? Tutti i suggerimenti sarebbero apprezzati. Grazie.

Answer 1

Prendi una copia di Working Effectively with Legacy Code di Michael Feathers. È pieno di consigli utili per lavorare con basi di codice grandi e non testate.

Un altro buon libro è Object Oriented Reengineering Patterns. La maggior parte del libro non è specifico per il software orientato agli oggetti. Il testo completo è disponibile per il download gratuito in formato PDF.

Dalla mia esperienza: cercare di ...

• automatizzare la compilazione e la distribuzione
• Prendi lo schema del database in controllo di versione, se non è ancora. Solitamente i database includono dati di riferimento che il codice transazionale deve esistere prima di poter funzionare. Prendi anche questo sotto controllo della versione. Strumenti come dbdeploy possono aiutarti a ricostruire facilmente uno schema e fare riferimento a dati da una sequenza di delta.
• Installare una versione del database (e qualsiasi altro servizio di infrastruttura) sulla workstation di sviluppo. Questo ti consentirà di lavorare sul database senza dover continuamente ricorrere agli amministratori di database. È 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 si è bloccati nella situazione poco invidiabile di sviluppo su Windows e distribuzione su Unix).
• Prima di iniziare a lavorare su un'area del codice, scrivere test end-to-end che coprano approssimativamente il comportamento dell'area su cui si sta 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 cambiare il codice per metterlo a posto. Agirà come un test di regressione (imperfetto) e ti darà più sicurezza nel rifattorizzare gli interni del sistema verso una struttura che è più facile da testare.
• Se ci sono piani di test manuali, leggerli e vedere cosa può essere automatizzato. La maggior parte dei piani di test manuali sono quasi interamente programmati e quindi i frutti a basso impatto per l'automazione
• Una volta ottenuta la copertura dei test end-to-end, riorienta il codice in unità più liberamente accoppiate mentre lo modifichi e/o lo estendi. Circonda queste unità con i test unitari.

cose da evitare:

• Copia dei dati da database di produzione nell'ambiente si utilizza per test automatizzati. Questo renderà i tuoi test imprevedibili.Certo, esegui il sistema con una copia dei dati di produzione, ma usalo per i test esplorativi, non per i test di regressione.
• Operazioni di rollback alla fine dei test per isolare i test l'uno dall'altro. Ciò non testerà il comportamento che si verifica solo quando le transazioni vengono impegnate e eliminerà i dati che sono utili per diagnosticare i fallimenti del test. Invece, i test dovrebbero garantire che il database sia in uno stato iniziale noto all'avvio.
• Creazione di un set di dati "minuscolo" per i test da eseguire. Ciò rende i test difficili da capire perché non possono essere letti come una singola unità. Il set di dati "minuscolo" diventa presto molto grande quando si aggiungono test per diversi scenari. Invece, i test possono inserire dati nel database per impostare il test-fixture.

Answer 2

“Testing Legacy Application Modernization,” mette in evidenza:

panoramica

1. alto livello di come i test sono create in AscentialTest

2. modi per convertire l'eredità oggetti ai nuovi componenti della piattaforma di Object definizione

3. Come assicurarsi che la versione aggiornata dell'applicazione produca gli stessi risultati

Per ulteriori dettagli sull'utilizzo di test delle applicazioni legacy, fare controllare qui:

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html