Devo usare try catch nei miei metodi di test?

Risposta breve: NO.

Non rilevare eccezioni nei test unitari. Sei un test unitario per trovare errori e situazioni in cui vengono sollevate eccezioni.

Il framework di test unitario dovrebbe gestire le eccezioni in modo sano. La maggior parte (se non tutti) i framework xUnit hanno un costrutto per aspettarsi alcune eccezioni che si usano quando si vuole indurre una particolare condizione di eccezione nel sistema sotto test e avere un test pass se viene sollevata l'eccezione prevista ma fallire se non lo fa.

(In contrasto con la risposta di mcottle) Risposta lunga: NO ... il più delle volte

Quando dici che ti aspetti che un test generi un'eccezione particolare, saprai quando QUALSIASI linea in quel test solleva quella particolare eccezione.

Non è proprio la stessa cosa che sapere che il metodo sotto test genera l'eccezione.

Se il tuo test prevede l'impostazione di un oggetto o di un contesto (all'interno del test, non all'interno della versione del framework di SetUp ), potresti trovarti meglio avvolgere la singola linea che vuoi testare in un try / catch, possibilmente con un aiuto.

Ad esempio,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

e poi

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

Se questo test fallisce, so che il mio metodo in prova ha gettato l'eccezione, e non qualcosa nelle cose di impostazione casuale.

(Dovresti cercare di evitare roba di configurazione casuale, a volte è più semplice avere un codice di configurazione nel test.)

In generale, dovresti semplicemente escludere l'eccezione e il framework di test ti fornirà un bel rapporto con tutte le informazioni di cui hai bisogno.

Ma nella metodologia TDD, ci si aspetta che segua questi passaggi:

1. Scrivi un test
2. Guardalo fallire e rendere comprensibile l'errore
3. Correggi il codice
4. Rifattore del codice e del test

Quando si rilascia un'eccezione, se l'errore è chiaro, allora va bene. Ma a volte l'eccezione è oscura o addirittura fuorviante. Come hai potuto lasciare che fosse nel tuo codice (per te più tardi quando avrai dimenticato, o per un membro del team che perderà un sacco di tempo a capire il problema)? Quindi la mia politica è: " Se è necessario rendere chiaro un errore, è necessario rilevare l'eccezione ".