2013-10-18 12 views
5

Ho davvero provato ad iniziare ad isolare i miei test di unità in modo da poter individuare dove si verificano gli errori piuttosto che avere il mio intero schermo diventare rosso con guasti quando una cosa va storta. Funziona in tutte le istanze tranne quando qualcosa in un inizializzatore fallisce.Un buon modo per isolare i test che dipendono da un inizializzatore

Guarda anche questi test:

@setup_directory(test_path) 
def test_filename(self): 
    flexmock(lib.utility.time).should_receive('timestamp_with_random').and_return(1234) 

    f = SomeFiles(self.test_path) 
    assert f.path == os.path.join(self.test_path, '1234.db') 

@setup_directory(test_path) 
def test_filename_with_suffix(self): 
    flexmock(lib.utility.time).should_receive('timestamp_with_random').and_return(1234) 

    f = SomeFiles(self.test_path, suffix='.txt') 
    assert f.path == os.path.join(self.test_path, '1234.txt') 

che sto beffarda metodi dipendenti in modo che la cosa di cui sono prova è completamente isolato. Quello che noti è che la classe deve essere istanziata per ogni singolo test. Se nell'inizializzatore viene introdotto un errore, ogni singolo test fallisce.

Questo è il costruttore incriminato che chiama inizializzatore della classe:

SomeFiles(*args) 

C'è un modo per isolare o deridere il costruttore inizializzatore o di un oggetto?

risposta

1

Non sono sicuro dei pacchetti di test che si stanno utilizzando, ma in generale, si può semplicemente prendere in giro la chiamata __init__() sulla classe prima di tentare effettivamente di utilizzarla. Qualcosa di simile

def my_init_mock_fn(*args, **kwargs): 
    print 'mock_init' 

SomeFiles.__init__ = my_init_mock_fn 
SomeFiles() 

Questo probabilmente non è esattamente quello che vuoi come da questo punto in SomeFiles.__init__ fn sarà sempre il fn finto, ma ci sono programmi di utilità come voidspace mock che forniscono una funzione di patch che consentono di patchare la classe solo per uno scopo specifico.

from mock import patch 
with patch.object(SomeFiles, '__init__', my_init_mock_fn): 
    SomeFiles() 
    ..other various tests... 
SomeFiles() #__init__ is reset to original __init__ fn 

Sono sicuro che probabilmente c'è una funzionalità simile in qualsiasi pacchetto di derisione che si sta utilizzando.

appena reso conto che si sta utilizzando flexmock, c'è una pagina per replace_withhere.

+0

Mock \ _ \ _ init__. Sembra una risposta semplice quando ci penso ora :) Ho usato flexmock per fare questo flexmock (SomeFiles) .should_receive ('\ _ \ _ init__') –

0

Cosa sta causando il fallimento della funzione di inizializzazione? Forse è un bug che dovresti esaminare.

Un'altra cosa che puoi fare, invece di prendere in giro il costruttore di oggetti, è semplicemente prendere in giro i suoi valori di ritorno. vale a dire: dato questo input, mi aspetto questo output, quindi userò questo output previsto indipendentemente dal fatto che sia stato restituito correttamente.

È inoltre possibile interrompere il test al primo errore. (failfast)

Si potrebbe anche voler riconsiderare come sono stati impostati i test. Se devi ricreare due file per ogni test, magari chiediti perché. I test possono essere strutturati in modo da configurare i due file, quindi eseguire una serie di test, risciacquo e ripetizione. Ciò farebbe sì che solo la serie di test assegnati a quel percorso fallisca, aiutandoti a isolare il motivo per cui non ha funzionato affatto.

+0

No, non sto chiedendo un bug specifico con un costruttore. Sto chiedendo come isolare il metodo \ _ \ _ init \ _ \ _ in una suite di test. I due test di esempio non stanno testando l'inizializzatore ma falliranno se c'è un errore nell'inizializzatore. Voglio essere in grado di scrivere un test che fondamentalmente prende in giro l'inizializzatore in modo da poter isolare un test per questo. –

Problemi correlati