Metodi di test di denominazione in Java [chiuso]

Naviga le tue risposte
6

Oltre a vista del codice un commento ha suggerito che l'uso di snake_case per denominare i metodi di prova è una buona idea.

Questo ha contraddetto le mie opinioni e ho fatto delle ricerche e sembra che ci siano molti esempi che effettivamente usa snake_case per questo.

Io stesso, uso i nomi classici di camelCase come testXyz per i test unitari o un approccio BDD givenXyzWhenXyzThenXyz per i test di integrazione.

Esiste anche una terza opzione che combina entrambi modi, ad es useCase_WhenSomething_ThenAssertion .

La mia domanda è : quali sono i buoni argomenti per l'utilizzo di snake_case o camelCase per denominare i metodi di test?

Vorrei iniziare con alcuni argomenti della mia esperienza e lavoro:

In favore di camelCase

  • Segue le convenzioni generali sulla codifica Java dell'uso di camelCase.
  • È coerente con codice di produzione.
  • I personalmente trovare camelCase non è più difficile da leggere rispetto a snake_case - Sono comunque abituato a nomi descrittivi dal codice di produzione.
  • Il supporto IDE soffre quando si utilizza snake_case (almeno Eclipse).

In favore di snake_case

  • Alcuni framework possono generare report dai test e l'uso di snake_case consente a tali framework di creare frasi corrette dai nomi dei test.

In favore di una combinazione di entrambi

Quali sono gli altri argomenti? In che modo forse il modello in cui i metodi di test sono denominati influenzano gli argomenti?

Piccolo disclaimer: ovviamente, in ultima analisi, si tratta di convenzioni di squadra. Tuttavia, potrebbe valere la pena discutere di pro e contro per alcune convenzioni.

    
posta Ingo Bürk 01.05.2014 - 10:08
fonte

1 risposta

9

Cederò alcuni centesimi perché si tratta del mio commento.

Anch'io ho avuto questo approccio di denominazione da Roy Osherove e mi piace particolarmente. Seguendo un metodo che è costruito in questo modo possiamo avere qualcosa di simile a questo: 

createUser_WithNonExistingEmail_ShouldThrowArgumentException

Nel Cammello standard questo diventa 

createUserWithNonExistingEmailShouldThrowArgumentException

Non è illeggibile, ma è molto più difficile da leggere. La ragione per cui questi underscore espliciti vengono aggiunti è perché i nomi dei metodi sono per definizione molto più lunghi se li rendi descrittivi come suggerito da Osherove.

Il nome metodo di un test unitario deve combinare diversi aspetti. Dovrebbe contenere

  • L'unità sottoposta a test
  • Lo scenario che viene testato
  • Il valore restituito previsto

Il nome metodo di un test non unitario deve contenere

  • L'azione principale eseguita da quel metodo

Da solo questo sommario dovrebbe indicare che questo è un tipo speciale di metodo. Mi sento come se potessimo deviare dal percorso delle convenzioni perché l'intenzione dietro i nomi dei metodi in questo scenario è diversa dai metodi tradizionali (che erano tenuti in considerazione quando sono state fatte le convenzioni).

I test unitari sono diversi dai metodi tradizionali anche in altri modi: non verranno mai chiamati da te esplicitamente e quindi dovrebbero essere il più possibile leggibili e descrittivi per i risultati del test.

    
risposta data 01.05.2014 - 13:42
fonte

Leggi altre domande sui tag

E 'una buona idea gestire un gruppo di microservizi di pronti contro termine come sottomoduli di un master repo? Perché un'interfaccia sostituisce i metodi delle interfacce che estende in Java 7?