Nel codice testato unitamente ho spesso più controlli sugli argomenti su qualsiasi metodo prima che inizi il vero "lavoro" del metodo:
public void DoSomething(string test)
{
if (string.IsNullEmptyOrWhiteSpace(test))
{
throw new ArgumentException("Test must not be empty", "test");
}
}
Nel mio test corrispondente per questo metodo farò quanto segue:
[Test]
[ExpectedException(typeof(ArgumentException),
Message = "Parameter name: test",
MatchType = MatchType.Contains)]
public void TestNullInput()
{
var classToTest = new ClassToTest();
classToTest.DoSomething(null);
}
Penso che questo sia un pessimo modo di fare il test, comunque, poiché si basa su uno specifico parametro chiamato (che non è necessariamente valido dopo ogni refactoring), così come il formato del messaggio di ArgumentException.
Un'altra opzione potrebbe essere quella di creare un'eccezione personalizzata per questo, qualche forma di "TestWasNullOrEmptyException", ma anche questo sembra abbastanza imbarazzante, poiché ci saranno molte molte eccezioni in tutta la soluzione, ciascuna usata per indicare solo l'assenza / invalidità di un parametro.
Mi chiedo se qualcun altro ha affrontato questo problema, e se sto semplicemente facendo i miei test di convalida dell'input nel modo sbagliato, c'è una soluzione più elegante.
EDIT: Questo è il codice C # e sto usando NUnit / Rhino Mocks.