Come scrivere test di integrazione per una piattaforma software orientata ai componenti

2

Situazione iniziale:

Stiamo sviluppando una piattaforma software in cui i prodotti possono essere generati configurando diversi componenti e aggiungendone altri. La piattaforma è sviluppata diversi anni da un piccolo team di sviluppatori. Ora la piattaforma è sempre più utilizzata, abbiamo nuovi sviluppatori e tester. Attualmente stiamo sviluppando un concetto per sviluppatore. La causa è che non abbiamo molti test di sviluppo per i nostri componenti.

Il team di tester utilizza strumenti di test UI automatizzati per testare i prodotti emessi dalla piattaforma.

Il nostro obiettivo:

Vogliamo motivare i membri del nostro team a scrivere più test per ottenere

  • abbreviare i cicli di feedback
  • riduce il conteggio degli errori per le nuove funzionalità
  • ridurre le regressioni

La domanda:

Vogliamo iniziare a capire i componenti fragili. Dopo averli trovati, vogliamo scrivere test di integrazione per il componente che descrive le funzionalità previste. Ora abbiamo il seguente problema: possiamo testare il componente per se stesso e prendere in giro tutte le dipendenze con altri componenti. Possiamo testare il componente con tutti i componenti direttamente dipendenti. Possiamo testare il componente con la sua struttura completamente dipendente, quindi le sue dipendenze e le loro dipendenze ... Possiamo testare il componente nel contesto di diverse configurazioni di prodotto.

Quale sarebbe il migliore per raggiungere i nostri obiettivi e allo stesso tempo ridurre al minimo lo sforzo richiesto dai membri del nostro team per configurare i test?

    
posta Yggdrasil 03.06.2013 - 13:42
fonte

1 risposta

1

Probabilmente avrai bisogno di entrambi.

I test di integrazione sono contro dipendenze reali. Di solito sono più facili da scrivere, ma richiedono più tempo e risorse per essere eseguiti. Alcuni bug verranno rilevati solo dai test di integrazione, poiché i bug reali delle dipendenze saranno influenzati e non penserai mai agli stessi bug quando prendi in giro. Testano anche tutti i componenti coinvolti, quindi pochi test per i componenti a valle ti daranno molta copertura.

I test unitari sono contro falsi. Scrivere i motti richiede tempo, ma i test si eseguono più velocemente ed è l'unico modo per testare la robustezza contro vari fallimenti, perché non si può far fallire la vera dipendenza in qualsiasi modo si pensi. Sono anche molto più facili da eseguire il debug.

Ti suggerisco di iniziare con i test di integrazione. Crea alcuni script per configurare tutti i dati di test necessari, quindi è facile da eseguire. Inizia con impostazioni grandi e realistiche. Questo dovrebbe aiutarti a identificare i componenti fragili. È possibile creare configurazioni più piccole per restringere le fonti dei problemi. Poi crea mock e unit test principalmente come strumento per rendere più facile il debugging dei difetti che hai trovato nei test di integrazione. E tenerli in giro come test di regressione.

    
risposta data 03.06.2013 - 15:59
fonte

Leggi altre domande sui tag