Perché utilizzare i corridori di prova?

2

Attualmente sto progettando un framework di test automatizzato per eseguire test di sistemi embedded su un sistema Linux embedded. Esiste un vecchio sistema, ma è particolarmente difficile da usare, principalmente perché non è stato progettato come un framework ed è stato originariamente progettato per testare un solo prodotto. Ciò significa che il framework cambia con ogni nuovo prodotto da testare, il che richiederebbe molto tempo per capire semplicemente dove modificare il sistema e come.

Ora, mi è stata data l'opportunità di creare un nuovo sistema da zero, con l'obiettivo di renderlo molto più facile da usare e molto più intuitivo. Una delle cose che ho notato sia nel vecchio sistema che negli altri sistemi di test che ho usato è stata l'idea di impostare tutti i test e le condizioni di verifica, e quindi eseguire il test in modo che la configurazione e il test correre erano due percorsi diversi che si verificavano in sequenza. Uno dei lati negativi di questo è che qualsiasi dichiarazione di stampa si verificherebbe al di fuori del percorso del flusso del tester attuale, quindi la stampa delle variabili non riuscite deve essere aggiunta al tester in qualche modo.

Ora che mi viene in mente di ridisegnare il sistema. Mi chiedo quali ulteriori vantaggi si presentino adottando un'architettura in stile test-runner semplicemente impostando le cose, controllando variabili e riportando tutte allo stesso tempo.

    
posta Ampt 11.06.2013 - 21:00
fonte

1 risposta

1

Suggerisco di dare uno sguardo al libro XUnit Test Patterns . Copre molti modi diversi per definire un framework di test e discute alcuni pro e contro di molti approcci diversi.

Penso che il miglior vantaggio dell'utilizzo di un test runner rispetto all'approccio che hai menzionato sia che diventa più facile eseguire un sottoinsieme dei test (che potrebbe essere solo uno di questi).

    
risposta data 12.06.2013 - 04:25
fonte

Leggi altre domande sui tag