Nie polecam używania atrybutu ExpectedException (ponieważ jest zbyt ograniczający i podatny na błędy) ani pisania bloku try / catch w każdym teście (ponieważ jest zbyt skomplikowany i podatny na błędy). Użyj dobrze zaprojektowanej metody asercji - dostarczonej przez środowisko testowe lub napisz własną. Oto, co napisałem i wykorzystałem.
public static class ExceptionAssert
{
private static T GetException<T>(Action action, string message="") where T : Exception
{
try
{
action();
}
catch (T exception)
{
return exception;
}
throw new AssertFailedException("Expected exception " + typeof(T).FullName + ", but none was propagated. " + message);
}
public static void Propagates<T>(Action action) where T : Exception
{
Propagates<T>(action, "");
}
public static void Propagates<T>(Action action, string message) where T : Exception
{
GetException<T>(action, message);
}
public static void Propagates<T>(Action action, Action<T> validation) where T : Exception
{
Propagates(action, validation, "");
}
public static void Propagates<T>(Action action, Action<T> validation, string message) where T : Exception
{
validation(GetException<T>(action, message));
}
}
Przykładowe zastosowania:
[TestMethod]
public void Run_PropagatesWin32Exception_ForInvalidExeFile()
{
(test setup that might propagate Win32Exception)
ExceptionAssert.Propagates<Win32Exception>(
() => CommandExecutionUtil.Run(Assembly.GetExecutingAssembly().Location, new string[0]));
(more asserts or something)
}
[TestMethod]
public void Run_PropagatesFileNotFoundException_ForExecutableNotFound()
{
(test setup that might propagate FileNotFoundException)
ExceptionAssert.Propagates<FileNotFoundException>(
() => CommandExecutionUtil.Run("NotThere.exe", new string[0]),
e => StringAssert.Contains(e.Message, "NotThere.exe"));
(more asserts or something)
}
UWAGI
Zwrócenie wyjątku zamiast obsługi wywołania zwrotnego sprawdzania poprawności jest rozsądnym pomysłem, z wyjątkiem tego, że powoduje to, że składnia wywołania tego asertu jest bardzo różna od innych twierdzeń, których używam.
W przeciwieństwie do innych, używam „propaguje” zamiast „rzuca”, ponieważ możemy jedynie przetestować, czy wyjątek propaguje się z wywołania. Nie możemy bezpośrednio przetestować, czy zgłoszony został wyjątek. Ale przypuszczam, że wyobrażenie o rzutach może oznaczać: rzucone i nie złapane.
KOŃCOWA MYŚL
Przed przejściem do tego rodzaju podejścia rozważałem użycie atrybutu ExpectedException, gdy test zweryfikował tylko typ wyjątku i użycie bloku try / catch, jeśli wymagana była większa weryfikacja. Ale nie tylko musiałbym zastanowić się, którą technikę zastosować w każdym teście, ale także zmienić kod z jednej techniki na drugą, gdy zmieniły się potrzeby, nie było trywialnym wysiłkiem. Stosowanie jednego spójnego podejścia oszczędza wysiłek umysłowy.
Podsumowując, podejście to cechuje: łatwość użycia, elastyczność i solidność (trudno to zrobić źle).