¿Debo usar try catch en mis métodos de prueba?

Respuesta corta: NO.

No atrapar excepciones en pruebas unitarias. Usted está realizando pruebas unitarias para encontrar errores y situaciones en las que se generan excepciones.

El marco de prueba de la unidad debe manejar las excepciones de una manera sana. La mayoría (si no todas) las estructuras xUnit tienen una construcción para esperar ciertas excepciones que usa cuando quiere inducir una condición de excepción particular en el sistema bajo prueba y tiene un pase de prueba si se genera la excepción esperada pero falla si no lo hace.

(En contraste con la respuesta de mcottle) Respuesta larga: NO ... la mayoría del tiempo

Cuando dice que espera que una prueba genere una excepción en particular, sabrá cuándo CUALQUIER línea en esa prueba genera esa excepción en particular.

No es exactamente lo mismo que saber que el método bajo prueba lanza la excepción.

Si su prueba implica configurar un objeto o contexto (dentro de la prueba, no dentro de la versión de su marco de SetUp ), es mejor que ajuste la línea individual que realmente desea probar en un try / catch, posiblemente con un ayudante.

Por ejemplo,

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);
        }
    }
}

y luego

[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 */})
}

Si esta prueba falla, sé que mi método bajo prueba arrojó la excepción y no algo en la configuración aleatoria.

(Debes intentar evitar las cosas de configuración aleatoria. A veces, es más fácil tener algún código de configuración en la prueba.)

En general, solo debe dejar salir la excepción, y el marco de prueba le dará un buen informe con toda la información que necesita.

Pero en la metodología TDD, se espera que sigamos esos pasos:

1. escribe una prueba
2. Míralo fallar y haz que el error sea comprensible
3. Corregir el código
4. Refactoriza el código y la prueba

Cuando dejas salir una excepción, si el error es claro, entonces está bien. Pero a veces la excepción es oscura, o incluso equivocada. ¿Cómo podría dejar que eso esté en su código (para usted más tarde cuando lo habrá olvidado, o para un miembro del equipo que perderá mucho tiempo resolviendo el problema)? Por lo tanto, mi política es: " Si es necesario aclarar el error, debe detectar la excepción ".