Il codice di prova di spedizione è una forma di controllo di integrità

4

Hai mai spedito il codice di test (JUnit, NUnit ecc.) con la tua applicazione che potrebbe essere eseguibile dall'utente finale?

Idea di base è questa:

L'applicazione può essere distribuita in un ambiente vario ed è difficile raccogliere tutta la possibile combinazione hardware-software o prerequisiti per l'applicazione. È comunque possibile scrivere una suite di test che asserisca che l'applicazione ha tutto ciò di cui ha bisogno per eseguire l'attività in questione. Sfortunatamente ciò deve essere fatto prendendo in giro alcuni componenti in modo che il test non influenzi l'ambiente di produzione reale.

Ci sono chiari vantaggi nella spedizione di questi test come:

  • dare al cliente un mezzo per verificare che il sistema sia in ordine.
  • fornisce rapporti per aiutare a supportare i problemi di diagnosi.
  • fornire mezzi per il team di implementazione per affermare che la loro configurazione dovrebbe funzionare
  • etc

Un modo naturale per farlo sarebbe avere un sottoinsieme di test che sono effettivamente pacchettizzati con l'applicazione (o come progetto separato o come parte di ciascun componente del tutto). Ancora più naturale sarebbe utilizzare gli strumenti e le tecniche che già utilizziamo per i nostri test di unità, ovvero la libreria di test delle unità, la struttura di derisione, ecc.

L'hai mai fatto? Come l'hai fatto? o perché pensi che questa sia una pessima idea?

    
posta Newtopian 19.12.2011 - 11:03
fonte

2 risposte

7

Chiamavamo questo test del fumo . Tuttavia, i test unitari non sono adatti a questo scopo, in quanto eseguono piccoli pezzi di codice in isolamento (quanto è grande la possibilità che il metodo di calcolo delle imposte smetta improvvisamente di funzionare?) Piuttosto, è necessario test di integrazione (chiamato anche test di sistema ) per eseguire il sistema nel suo insieme e assicurarsi che sia assemblato e configurato correttamente.

La suite per il test dei fumi può essere un sottogruppo semplice e piccolo della suite di test di integrazione / funzionalità completa, solo per verificare che il sistema nel suo complesso possa essere avviato e possa eseguire correttamente alcune delle sue funzionalità di base. Preferibilmente dovrebbe essere

  • sicuro da eseguire sul sistema reale, attivo (ovvero non apportare modifiche ai dati persistenti),
  • banale da eseguire (con un singolo comando o premendo un pulsante),
  • veloce e
  • la sua uscita concisa e non ambigua, come quella dei test unitari (ad esempio "Success" o "Test Foo and Bar falliti con i seguenti errori: ...").

E sono d'accordo con Thorbjörn sul fatto che questo dovrebbe essere eseguito - o almeno avviato - dal deployer / installer, o dal personale di supporto in caso di problemi di sistema successivi.

Abbiamo usato e stiamo usando tali test su diversi progetti, anche se tutti questi sono sviluppi lato server, gli utenti finali che eseguivano test fumo non erano in genere nemmeno un'opzione. Dal lato del cliente, ovviamente, l'immagine è diversa. È possibile prendere in considerazione l'idea di sottoporre a test del fumo il passaggio finale del processo di installazione e / o documentarne l'utilizzo per la risoluzione dei problemi. In alternativa, se sono abbastanza veloci, potrebbero anche essere eseguiti automaticamente all'avvio, sempre.

    
risposta data 19.12.2011 - 11:24
fonte
1

Perché l' utente finale fa questo?

Per me questo fa parte della linea di distribuzione (dove potrebbe essere una buona idea molto ). Se mai, allora tu verrebbe eseguito in modo silenzioso su base regolare oppure l'utente finale lo farà sulla tua richiesta.

    
risposta data 19.12.2011 - 11:12
fonte

Leggi altre domande sui tag