Strategia di test per sistemi accoppiati

Question

Strategia di test per sistemi accoppiati

Naviga le tue risposte

#1 da (1 voti)

0

Abbiamo 2 applicazioni accoppiate: una vista ReadOnly e una vista di gestione amministrativa.

La vista ReadOnly viene aggiornata dalle modifiche apportate dalla vista Amministratore.

Ogni applicazione appartiene a team diversi. Ogni applicazione dovrebbe essere distribuita separatamente.

Fondamentalmente, non siamo chiari su come eseguire i test di integrazione senza doverli testare continuamente.

In questo momento apriamo la vista ReadOnly, controlliamo alcune ipotesi, apriamo la vista Admin e modifichiamo i dati, quindi ricarichiamo la vista ReadOnly per verificare che le cose siano aggiornate come previsto.

Qualcuno può dare un feedback sul fatto che ci sia un modo migliore?

Nell'approccio attuale, dovremo eseguire 2 serie di test di integrazione per ogni modifica alla vista ReadOnly o alla vista Amministratore. In effetti, abbiamo alcune visualizzazioni di ReadOnly (diversi prodotti) che verrebbero eseguite in questa materia.

Qualsiasi feedback / pensiero è apprezzato!

integration

posta dulac 15.06.2015 - 19:20

fonte

1 risposta

Leggi altre domande sui tag integration

Come dovrei refactoring un singleton (che deve essere usato da un contenitore) quando la classe refactored richiede l'inizializzazione e prende una dipendenza? Le migrazioni dovrebbero modificare i dati?

score 1 · Answer 1

Se comprendo correttamente la tua domanda, entrambe le viste accedono ad una sorta di stato (presumibilmente in un database), l'AdminView è in grado di modificarlo e leggerlo, e la vista ReadOnly può solo leggerlo. In tal caso ...

La maggior parte dei test (in particolare la maggior parte dei test automatici) dovrebbe testare solo una di queste visualizzazioni.

I test di visualizzazione di ReadOnly dovrebbero assumere il formato "Ecco alcuni dati, consegnarli alla vista, fare apparire i widget giusti sullo schermo?"
I test di AdminView dovrebbero assumere il formato "Ecco alcuni dati, eseguire un'operazione su di esso, i dati modificati sembrano corretti?" o forse "ecco alcuni dati, fai apparire i widget giusti, fai clic su questo widget, i dati modificati sembrano corretti?".
I "dati" a cui mi riferisco in modo nebuloso dovrebbero avere un qualche tipo di schema (che si tratti di uno schema di database, uno schema XML, uno schema JSON, qualunque) che definisca in modo completo, non ambiguo e preciso le possibili forme che questi dati possono assumere . Finché questo schema non cambia mai in modo incompatibile all'indietro, testare ciascuna vista in modo isolato rimane una strategia valida.

Ovviamente vorrete comunque testare le due viste insieme (incluso il codice della colla che parla con il vero database), ma non è necessario che siano suite di test super-approfondite. In effetti, provare a creare una suite di test di integrazione super-completa causa di solito un'esplosione combinatoria senza speranze nella pratica. Sono i "test unitari" (o almeno i test a vista singola) in cui vale la pena dedicare del tempo a ottenere un ciclo di feedback stretto per TDD red-green-refactor e / o copertura del codice perfetta per aumentare la sicurezza nei test " risultati.