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

Estoy haciendo pruebas unitarias.

Estoy tratando de probar una función.

Lo llamo desde mi componente de prueba. Pero si la función remota no puede manejar la excepción, supongo que mi componente de prueba también obtendrá una excepción.

Entonces, ¿debería preocuparme por obtener una excepción en mi componente de prueba?

Gracias.

EDITAR:

PD:

Lanzar un error es bueno, pero solo para otras funciones, ¡no para usuarios finales hasta que sea una última opción!

Dios mío, escribí una cita de programación !!

Respuesta corta: NO.

No atrape excepciones en las pruebas unitarias. 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 manera sensata. La mayoría de los marcos de xUnit (si no todos) tienen una construcción para esperar ciertas excepciones que usted usa cuando desea inducir una condición de excepción particular en el sistema bajo prueba y tiene una prueba aprobada si se produce la excepción esperada, pero falla si no lo hace.

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

Cuando diga que espera que una prueba provoque una excepción particular, sabrá cuándo CUALQUIER línea de esa prueba genera esa excepción particular.

Eso no es lo mismo que saber que el método bajo prueba arroja 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 trabajo SetUp), es mejor que ajuste la línea única que realmente desea probar en un intento / captura, 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 entonces

[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.

(Debería intentar evitar cosas de configuración aleatorias. A veces, es más fácil tener algún código de configuración en la prueba).

En general, 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. Escribir una prueba
2. Míralo fallar y haz que el error sea comprensible
3. Corrige el código
4. Refactorizar el código y la prueba.

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