Domanda

Sto cercando di migliorare il test unitario del mio codice, ma in questo momento sto scrivendo molto codice che riguarda i sistemi remoti.SNMP, WMI, quel genere di cose.Con la maggior parte delle classi posso simulare oggetti per testarli, ma come gestisci il test unitario di un sistema reale?Ad esempio, se la mia classe esce e ottiene l'oggetto Win32_LogicalDisk per un server, come potrei testarlo?

È stato utile?

Soluzione

Supponendo che tu intendessi "Come posso testare cose che sono difficili/impossibili da deridere":

Se hai una classe che "esce e ottiene l'oggetto Win32_LogicalDisk per un server" E fa qualcos'altro (consuma l'oggetto 'Win32_LogicalDisk' in qualche modo), supponendo che tu voglia testare i pezzi della classe che consumano questo oggetto, tu poter usare Iniezione di dipendenza per permetterti di deridere l'oggetto 'Win32_LogicalDisk'.Ad esempio:

class LogicalDiskConsumer(object):

    def __init__(self, arg1, arg2, LogicalDiskFactory)
        self.arg1=arg1
        self.arg2=arg2
        self.LogicalDisk=LogicalDiskFactory()

    def consumedisk(self):
        self.LogicalDisk.someaction()

Quindi, nel codice del test unitario, passa un "LogicalDiskFactory" che restituisce un oggetto fittizio per "Win32_LogicalDisk".

Altri suggerimenti

Il modo più semplice per testare cose difficili da deridere è rifattorizzare il codice in modo che il tuo codice (logica che vale la pena testare) sia in un posto e le altre cose che il tuo codice utilizza siano in moduli separati.Il modulo è facile da deridere e in questo modo puoi concentrarti sulla logica del tuo business.

Potresti creare una serie di "stub di test" che sostituiscano le routine della libreria principale e restituiscano valori noti, magari dopo adeguati ritardi.

Ad esempio, di recente ho avuto bisogno di sviluppare codice da eseguire all'interno di un prodotto di terze parti.La sfida era che il nostro "partner" si occupasse della compilazione e dell'integrazione con il loro codice di base:Non mi è stato permesso guarda a il loro codice in qualsiasi forma!La mia strategia era quella di costruire un emulatore molto semplice che facesse quello che volevo Pensiero il loro codice lo ha fatto, sulla base delle informazioni dei loro ingegneri.Abbiamo utilizzato un linguaggio che semplificava il passaggio e l'estrazione di varie parti dell'emulatore da ogni build, in modo da poter eseguire un'enorme quantità di test prima di coinvolgere il nostro partner nella creazione di ogni nuova iterazione.

Utilizzerei di nuovo lo stesso metodo, poiché i problemi software in quel particolare prodotto sono circa un ordine di grandezza inferiori rispetto al nostro prossimo prodotto più affidabile!

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top