Non mirare al 100% della copertura del codice. E di solito non scrivo test di metodi che ovviamente non contengono alcuna logica di business e / o più di poche righe di codice. Ma continuo a scrivere test unitari (usando TDD) di metodi che non sembrano così complessi. Ciò è dovuto principalmente al fatto che mi piace avere già il test unitario, quando si ritorna a quel codice mesi o anche anni dopo, e voglio renderlo più complesso. È sempre più facile estendere i test esistenti, piuttosto che doverli costruire da zero. Come diceva Noufal, è soggettivo. Il mio consiglio è di scrivere i test, se pensi che il metodo sia un po 'complesso o abbia il potenziale per diventare più complesso.

Questa è la seconda domanda TDD oggi che trasmette fastidio al numero di test da scrivere.

"Provalo solo se vuoi che funzioni."

Non sono sicuro di aver compreso il test nella domanda.

Stai verificando che Controller.Check () delega al servizio (dipendenza) l'argomento come valore del file selezionato dalla vista? Se sì, questo è un buon test. Ti permette di testare il controller senza l'effettiva implementazione del servizio. (micro-test basati sull'interazione).

Aggiornamento: Ora che sono chiaro su ciò che stai provando a testare, probabilmente sposterei un po 'di codice e rinominerò alcune cose in modo che legga "delegati di Test Media Controller selezionati" verifica del file sul servizio multimediale. " - che è una specifica valida per il controller.

public class TestMediaController

@Test
public void DelegatesSelectedFileCheckToMediaService(){
    string selectedMediaFileInView = "c:\Dir\file.avi";

    when(_view.getSelectedFile).thenReturns(selectedMediaFileInView);

    new MediaController(_service, _view).check();

    verify(_service).check(selectedMediaFileInView);
}

Non scriverei un test del genere (o almeno non lo chiamerei così). Invece, scriverei un test per la funzione che richiede quella chiamata a check() , in modo che se quel controllo o un'azione equivalente non viene eseguita, la funzione di alto livello non funzionerebbe. Perché il tuo codice deve chiamare il metodo check() ?

In generale, cerco di mantenere i test disaccoppiati dai dettagli di implementazione, in modo che almeno il nome del test parla solo delle funzionalità esterne fornite dall'oggetto. I dettagli di implementazione come oggetti e metodi non sono menzionati nel nome del test.

Questo rende più facile eseguire il refactoring (non dovrebbe essere necessario cambiare test quando si cambia l'implementazione) e sarà anche più facile scoprire se un test non è aggiornato (la funzione che specifica non è più necessario). Inoltre, renderà più semplice notare il codice non necessario / non valido, poiché la piastra di basso livello (come getter e setter) verrà aggiunta / conservata solo se richiesta da funzionalità di livello superiore.

Questo è soggettivo. Io non sempre faccio TDD, ma quando lo faccio, cerco di mantenere la copertura del codice come parametro per verificare se i miei test sono completi o meno. A volte, divento pigro e semplicemente salta le parti che a me sembrano "ovvie". A volte, violento il ciclo Red, Green, Refactor e scrivo più codice di quanto sia necessario, ma con il passare del tempo, sono entrato in un ritmo più comodo di me.

Interazioni tra classi come sopra e l'originale più semplice per cui scriverei un test. Le interazioni possono diventare più complesse nel tempo, quindi avere il lavoro a terra è una buona cosa.

If someone or I add more interesting code in the future I can create test for it then. Why should I do it now for the trivial cases?

Supponi che in futuro qualcuno saprà che questo elemento dell'interfaccia utente esiste e che cosa chiama sul back-end.

Il mio attuale progetto ha oltre 30 sviluppatori in sei team distinti all'interno della stessa base di codice. Le aggiunte UI banali scompaiono continuamente nella nebbia. Nessuno tornerà indietro e aggiungerà un caso di prova per questo in seguito perché nessuno ricorderà che è lì e quando si rompe la domanda diventa "Perché non hanno scritto un test? Sarebbe stato così semplice!"

Come al solito ...

Dipende

È difficile vedere l'utilità di questo particolare test in un contesto TDD perché non conosciamo la storia.

Se la storia è     In qualità di [utente multimediale]     Voglio [essere in grado di verificare la validità dei media]     In modo che [saprò quando un file non è disponibile]

quindi lo scenario     Dato [un pulsante di media di controllo]     Quando [l'utente fa clic sul pulsante]     Quindi [la validità del file è selezionata]

ha un senso. È banale, ma ha senso.

Se la trama generale è più grande di questa, la definizione dello scenario potrebbe essere troppo ristretta.

Ricorda:

TDD! = Test unità

Test TDD caratteristiche . Se si tratta di una funzione, allora merita un test per verificarlo.