Come convinco qualcuno che il test dovrebbe fare asserzione (non asserzioni) e non i metodi di supporto

Qui sotto suppongo che i metodi di aiuto che mostri siano aiutanti test , non parte del codice di produzione (questo non è chiaro dal tuo post, come già notato @Martin).

There are two many assertions happening in one method, though indirectly and it defeats the idea of one responsibility per test

Personalmente non prendo la regola "one assertion per test" (o potrei chiamarla dogma). Preferisco essere pragmatico e nella mia esperienza una tale regola ostacolerebbe lo sviluppo. La mia regola è "uno scenario per test" e questo singolo scenario potrebbe richiedere più asserzioni per verificare i risultati.

Tuttavia, sono d'accordo sul fatto che avere asserzioni mescolate a chiamate al codice sotto test sia alquanto confuso. Preferisco lo stile Arrange-Act-Assert per rendere più chiari i miei test, non solo per gli altri, ma anche per il futuro. Ciononostante, spesso metto una o più asserzioni in metodi di supporto dedicati: solo in questo caso, quei metodi helper sono pensati solo per asserire risultati, non per agire , e loro nome riflette questo.

Ora, in ogni caso, essendo il nuovo ragazzo del team, è meglio capire e abituarsi alle pratiche e alle convenzioni già stabilite dal team, al fine di diventare un utile membro del team (o iniziare a cercare un posto di lavoro migliore se davvero senti davvero che non puoi prenderlo). Dopo di ciò, puoi gradualmente iniziare a infondere le tue idee e pensieri, anche le critiche, nel processo di pensiero della squadra. Ma cercare di cambiare le convenzioni di squadra in anticipo, senza dimostrare il tuo valore e ottenere il rispetto dei tuoi colleghi prima, sarà un'esperienza inutile e frustrante per te .

There are times when I want to do one assertion in my test method while testing for a work flow. And many of the helper methods which would be called would assert things and might even fail which would hamper work flow test.

Due note:

• Perché le asserzioni falliscono? Il mio primo istinto è che in una buona prova non dovrebbero, e rimuovere le asserzioni fallite può effettivamente nascondere un vero problema.

• Che cosa ti impedisce di refactoring i metodi helper? Per es.

  public void doLoginWithoutAssert(String userName, String password) {
       //login here
  }
  
  public void doLogin(String userName, String password) {
       doLoginWithoutAssert(userName, password);
       AssertTrue("Login Successful");
  }
  

  In questo modo puoi chiamare l'aiutante senza asserzioni mentre i tuoi colleghi continuano a chiamare i loro aiutanti originali e tutti sono felici.

Il problema con questo approccio è che contrariamente ai "assert" reali (suppongo stiamo parlando di Java qui), il codice non viene rimosso dal compilatore durante la compilazione per una versione di produzione. Rimane lì. Certo, è solo un "se" che impiega 0,0001 secondi per completare e le prestazioni non saranno influenzate molto, ma mi sembra che inquini il codice.

Capisco che il tuo codice di test è più piccolo, ma quello che leggo sempre ovunque è che il codice di test non deve essere confuso con il codice aziendale. Inoltre, il tuo codice di produzione ha molto probabilmente una dipendenza da un framework di test. Tuttavia, il tuo collega collega potrebbe forse iniziare una nuova tendenza? ; -)

Inoltre, all'inizio pensavo che il tuo collega stesse usando il Assert che viene utilizzato principalmente per controllare i parametri del metodo. Se gli piace la parola chiave "assert", potresti invece convincerlo a usarlo, anche se non ha nulla a che fare con il test: -)

Fai la domanda: "Qual è la responsabilità di questi metodi di supporto?" E 'che il metodo helper dovrebbe fare qualche operazione e return un valore che indica che l'operazione è andata a buon fine, o è che il metodo helper fa qualche operazione e se non ha successo dovrebbe farlo ad alta voce in un altoparlante (piuttosto che bisbigliare il restituire al chiamante) sul fallimento dell'operazione e quindi renderli dipendenti dall'altoparlante a cui possono gridare.

Sembra che le asserzioni dei test divengano un po 'complicate poiché i metodi più comuni sono chiamati più volte durante il test, le asserzioni saranno fatte più volte contemporaneamente. Di solito vuoi un'affermazione per test.

Dal punto di vista della manutenibilità suppongo che il codice di test sia a posto, anche se personalmente preferisco i test refactor in modo che i comuni codici di setup (che non sono nel metodo @Before ) vengano estratti ai loro stessi metodi. Questi metodi estratti di solito prefisso con when come metodo è denominato whenLoginIsPerformed(…) (terminologia tratta dalla Mockito struttura di simulazione ). Ciò che tu chiami non ha molta importanza se vuoi passare dal AAA come mnemonico, puoi aggiungerlo con arrange , ad esempio il metodo è denominato arrangeLoginIsPerformed(…) .