2015-11-25 12 views
5

Sto tentando di utilizzare l'approccio di Presenter-First a un nuovo progetto. Di seguito mi trovo con unittest. Sto utilizzando le scarse pratiche di test unitario includendo così tante asserzioni in questo test? Se sì, è il problema con il mio approccio al test o all'implementazione di presenter.setOverview? In altre parole, il metodo setOverview dovrebbe chiamare self.setSalesQty piuttosto che self.view.setSalesQty? In questo caso, avrei un test separato per presenter.setSalesQty e il test testSetOverview non avrebbe più bisogno di preoccuparsi di testarlo.Presenter-First Unittest con multiple asserzioni

def testSetOverview(self): 
    # set up mock objects 
    p = PropertyMock() 
    type(self.mock_model).descriptions = p 
    self.mock_model.getData.side_effect = [5, 10] 
    self.mock_model.getDescription.side_effect = 'Description' 

    # get required variables 
    end = dt.date.today() 
    start = dt.date(year=end.year, month=1, day=1) 
    pn = 'abcd' 

    # call presenter method 
    self.presenter.setOverview(pn) 

    # test to make sure proper calls were made 
    model_getData_calls = [call(pn=pn, start=start, end=end, 
         data=self.mock_model.SHIPPED_QUANTITY), 
        call(pn=pn, start=start, end=end, 
         data=self.mock_model.PRICE_PAID)] 

    self.mock_model.getData.assert_has_calls(model_getData_calls, any_order=True) 
    assert self.mock_model.getDescription.called 

    self.mock_view.setSalesQty.assert_called_with(val=5) 
    self.mock_view.setSalesDols.assert_called_with(val=10) 
    self.mock_view.setDescription.assert_called_with(val='Description') 

risposta

1

Quindi, generalmente, durante la scrittura di test di unità, si desidera testare una cosa specifica. Perché quando scrivi più codice e il test fallisce sarà molto più facile per te capire cosa non ha funzionato nel test dell'unità. Può essere che con le affermazioni che hai fatto finora stai testando un comportamento o funzionalità del codice, allora le asserzioni vanno bene.

Per fare un esempio, avete due funzioni sotto list_counter dipende da word_count. Pertanto, durante il test di list_counter potresti fare due asserzioni per assicurarti che i due componenti in list_counter siano corretti. Ma probabilmente sarebbe più saggio testare word_count separatamente.

def word_count(word): 
    return len(word) 

def list_counter(listing=None): 
    total = 0 
    for l in listing: 
     total += word_count(l) 

    return (len(listing), total) 

È difficile commentare in modo più specifico sul tuo caso poiché non ho accesso a come appare il modello. self.mock_view appare anche dal nulla.

+0

non inserire più informazioni su self.mock_view e self.mock_model era intenzionale - questi sono oggetti fittizi, e come tale (a mio avviso) non dovrebbero essere sottoposti a test. Lo stesso Presenter è sotto test e dipende da questi due oggetti e li utilizza per fare il suo lavoro. – wesanyer

+0

Sì, non dovrebbero essere testati, ma vedere gli oggetti che rappresentano può aiutare a darti consigli su come scrivere il test. – Jonathan

+0

Abbastanza giusto. L'approccio che stavo prendendo, tuttavia, in linea con "il presentatore prima" era, beh, scrivere prima i test unitari del presentatore e l'implementazione. Prima ho scritto qualcosa per il modello o la vista. Ho preso in prestito i mock come segnaposto e, dopo aver scritto i test e l'implementazione del relatore, ho utilizzato le chiamate al metodo deriso come punto di partenza per il mio modello e per visualizzare i test e l'implementazione dell'unità. È atipico? – wesanyer