Come posso testare parti della mia applicazione contro l'uscita di applicazioni di terze parti?

È possibile trasferire i file di output esistenti (già elaborati nei file precedenti) nella cartella di output solo per simulare il lavoro dell'API di terze parti nel codice di test dell'unità. Questo è sufficiente se stai testando le tue funzionalità e non le funzionalità di terze parti.

Benvenuti nel mondo dei test di integrazione.

Il modo migliore per avvicinarsi a questo è strumenti automatici che possono esercitare la tua app di terze parti direttamente (se possibile) o tramite un involucro sottile. Scrivi un banco di prova per inviare vari dati al componente e ispeziona ciò che viene fuori, preferibilmente con un controllo automatico - ad esempio esegui un'espressione regolare sul contenuto del file e verifica se corrisponde a ciò che ti aspetti. A questo proposito è molto simile al test delle unità, tranne per il fatto che sono necessari diversi strumenti per verificare i risultati.

Per le parti della tua applicazione che eseguono il componente di terze parti, dovrai comunque controllare che funzioni correttamente. Potresti non essere in grado di utilizzare gli stessi framework di test di unità di cui avrai bisogno per controllare la lettura dei dati correttamente, e per questo avrai bisogno di un file da leggere. Immagino che tu possa scrivere un file standard nelle routine di test delle tue unità, ma sembra molto lavoro per pochi risultati. Personalmente, manterrei un set di file di esempio e li copierò nel posto giusto uno alla volta mentre esegui i test. (intendiamoci, anch'io li eseguirò come parte di uno strumento esterno, piuttosto che un quadro di test unitario "interno")

Ovviamente puoi testare il resto del tuo programma avvolgendo le chiamate verso la terza parte nella tua interfaccia e facendoti beffe di questo al costo di un ulteriore livello di astrazione nel tuo codice.

Dipende tutto da cosa stai provando a testare. Se vuoi testare solo la tua applicazione perché l'applicazione di terze parti è già stata testata, allora:

1. Unit test le chiamate che creano dati sulla cartella in un modo che non crea realmente questi file (non si desidera utilizzare il file o il database durante il test dell'unità). Ad ogni modo, se usi .NET, sai già che il salvataggio del file funziona (fa parte del framework)
2. Unit test la funzione che viene chiamata quando viene innescato l'evento del nuovo file nella cartella. Ancora una volta, non c'è bisogno di una vera cartella, è sufficiente iniettare i dati già elaborati nella tua funzione.

Questo renderà un test unitario davvero veloce di tutto il tuo codice.

Ma ... Se vuoi testare l'interazione con la terza parte o con il file system, allora quello che ti serve è il test di integrazione, il che significa che testerai tutte le parti che sono già state testate in unità e asserisci come funzionano insieme. Questo può essere fatto con un software di automazione della GUI come Ranorex o se il software viene attivato da un evento come "La cartella è stata aggiornata con un nuovo file?", puoi semplicemente fare un .bat che faccia il trucco.

Ad ogni modo, so che quello che sto dicendo è stato formulato con altre parole in un'altra domanda, ma penso che fosse importante capire la differenza tra test unitario e test di integrazione.

Spero che ti aiuti!

esegui test delle unità per prendi in giro il componente di terze parti, in modo da non controllare il comportamento di quel componente ma piuttosto solo il tuo, e lo fai < strong> test di integrazione includendo il componente di terze parti nei test e controllando che l'intero insieme funzioni insieme. Né preclude la necessità di fare l'altro; mentre si desidera controllare attentamente che la propria parte trasmetta correttamente le informazioni, è comunque necessario assicurarsi che non si stia facendo qualcosa di stupido a cui l'altro componente non piace (ad esempio, passando le opzioni sbagliate o una password mal codificata).

Si noti che i test di integrazione sono molto più difficili dei test unitari, in quanto è necessario verificare con un ambiente che sia almeno parzialmente equivalente a una distribuzione reale. (Al momento, sto lavorando con un'applicazione che è molto difficile da distribuire automaticamente, quindi il nostro test di integrazione è un PITA totale in quanto non può essere collegato con il nostro sistema CI ...)

Il test dovrebbe verificare se si spinge i documenti corretti (qualunque cosa significhi nel proprio scenario) per correggere la cartella. Quindi controlla se fai ciò che dovresti quando vengono visualizzati nuovi documenti nella cartella che controlli.