I test delle unità sono diventati instabili dopo l'aggiornamento di compilatori e IDE

Question

I test delle unità sono diventati instabili dopo l'aggiornamento di compilatori e IDE

#1 da (3 voti)

1

Ho una serie di circa 300 test unitari che hanno attraversato alcuni mesi difficili. I test scadenti sono stati oggetto di aggiornamento da un compilatore V110 (Visual Studio 2008) insieme a Visual Studio 2012 a un compilatore V120 (Visual Studio 2013) insieme a un aggiornamento a Visual Studio 2015.

Questi test stavano passando in VS2012. Hanno rotto in modo orribile dopo l'aggiornamento del compilatore / IDE. Alcune cose erano molto strane, ho passato settimane a cercare di sistemarle, ho lavorato con diversi ingegneri e ho trovato pochissima trazione. Poi un raggio di speranza è arrivato sotto forma di VS2015 Update 3. Ha risolto i test. Per circa 2 giorni. Ora ho incontrato un temuto "Impossibile configurare il contesto di esecuzione per eseguire il test", per un test che ha funzionato la settimana scorsa.

Quindi, i test sono stati un po 'malconcio di recente. Questi sono test critici che il mio team deve eseguire (e che non possiamo inserire le build gated a causa dei test falliti). Abbiamo soluzioni alternative per eseguire i test pezzo per pezzo, in un IDE precedente, dalla riga di comando, o qualsiasi altro numero di trucchi e hack ... ma non possiamo davvero avere trucchi e hack per importanti test unitari.

Non sto chiedendo come risolvere questo insieme specifico di test, ma inoltre come dovrei, come ingegnere del software, iniziare a riguadagnare la stabilità con una serie di test unitari divenuti instabili. Mentre sto scrivendo, la risposta sembra ovvia: scatta il più piccolo sottoinsieme di test falliti e analizza i fallimenti / avvia il processo di debug (che ovviamente sto facendo), ma le cose hanno sempre un strofinare. L'aggiornamento è avvenuto, e non si può tornare indietro, quindi al momento siamo bloccati con alcuni (occasionalmente) test inaffidabili.

Poiché i test possono essere eseguiti (non con facilità e non sempre tutti), la correzione di questi test non sembra mai essere una priorità più alta per il mio team che spingere nuove funzionalità. Sono un SD1 e quindi non ho molta influenza per convincere i membri più anziani del team ad analizzare questi test falliti e mi sento come se stessi ruotando le ruote cercando di fissare i test mentre aspetto il prossimo test / Errore dell'utensile. Cosa dovrei fare?

unit-testing

posta PerryC 05.07.2016 - 18:07

fonte

1 risposta

Leggi altre domande sui tag unit-testing

Usando l'ID del record della tabella come nome dell'immagine Devo creare un nuovo modello per una vista filtrata del modello esistente?

score 3 · Accepted Answer

Il problema che descrivi non è in alcun modo limitato ai test unitari, e quando ci si avvicina da una prospettiva di ingegneria del software, si potrebbe porre la domanda più generale

"Abbiamo scelto un certo framework come piattaforma per il nostro sistema di programma, ma quando eseguiamo l'aggiornamento a una versione più recente, incontriamo molti problemi di compatibilità imprevisti, perché il fornitore non ha fatto un buon lavoro rispetto al basso compatibilità. Cosa possiamo fare? "

Le possibili risposte a questa domanda potrebbero non piacervi, ma le misure sono ben note:

assicurati che il tuo software non sia più strettamente accoppiato al framework di quanto sia assolutamente necessario
assicurati che ogni volta che installi un aggiornamento del framework, c'è un modo per tornare alla versione precedente quando questo causa troppi problemi
assicurati di conoscere bene il tuo framework ed evita di utilizzare immediatamente le "ultime e migliori funzionalità", meglio essere un po 'prudenti, affidarti a funzioni mature
quando i problemi diventano intollerabili, considera di cambiare la tua piattaforma. Cerca di scegliere un framework che ha una reputazione di essere maturo e stabile, soprattutto quando si tratta di compatibilità con le versioni precedenti.

Nel tuo caso, ad esempio, hai utilizzato il quadro di test unitario di Visual Studio. Ovviamente, i framework spesso ti costringono ad accoppiare il tuo software strettamente, ma in questo caso, ogni volta che devi modificare l'IDE, devi anche aggiornare l'ambiente di test delle unità. AFAIK non è possibile aggiornare questi componenti singolarmente. Come hai scritto, al momento non esiste una via facile per tornare a una versione precedente di VS.

Quindi c'è un'alternativa? Sì, c'è - scegli un diverso framework di test delle unità che non sia così strettamente collegato all'IDE. I test unitari direttamente all'interno dell'IDE sono una bella trovata, ma nulla di cui non puoi vivere senza.

Ad esempio, abbiamo una suite completa di test delle unità per uno dei nostri prodotti da più di dieci anni, sviluppata con NUnit, e non abbiamo mai riscontrato nessuno dei problemi che hai menzionato quando abbiamo aggiornato da VS 2003 al 2015 con quasi tutti i livelli intermedi Versione VS rilasciata da Microsoft. NUnit era disponibile in un momento in cui non esistevano test delle unità VS, e al giorno d'oggi ci sono plugin VS per eseguire i test NUnit direttamente dall'interno dell'IDE. Tuttavia, quest'ultimo è ancora superfluo, possiamo anche eseguire tutti i test al di fuori di VS, semplicemente utilizzando la GUI NUnit.

Naturalmente, quando abbiamo aggiornato la versione di NUnit di tanto in tanto, abbiamo dovuto affrontare alcuni problemi minori, ma mai nulla di così grave come lo hai descritto, nemmeno vicino.

Potrebbero esserci altri framework di test delle unità con proprietà simili e anche non così impigliati con l'IDE; la scelta corretta ha sicuramente bisogno di una valutazione per il tuo caso. E quando scegli un framework di questo tipo, hai un altro fornitore di terze parti su cui devi fare affidamento, che può avere anche molti nuovi svantaggi e dipendenze. Forse la nostra squadra è stata solo fortunata a scegliere "il migliore" quadro diversi anni fa. Se uno non è così fortunato, e sceglie un quadro che viene abbandonato dopo alcuni mesi dal venditore - beh, succede un cazzo.

Ma penso che questa sia la migliore raccomandazione che posso darti qui. Forse cambiare la struttura non è un'opzione per te ora, potrebbe causare troppi sforzi. Forse dopo aver analizzato il tuo codice e aver pensato a questo, lo sforzo potrebbe non essere così alto come sembra a prima vista. Forse puoi isolare la maggior parte dei problemi che hai ora e avere sotto controllo i tuoi problemi usando quello che hai ora. Ma non aspettarti il proiettile d'argento: le decisioni relative alle strutture e alle biblioteche hanno sempre il rischio di rivelarsi sbagliato in futuro, non sei il primo a fare l'esperienza.