Test di autofirmazione per parametro costruttore non valido

Question

Ho la seguente classe e test. Voglio testare il passaggio di un valore null come parametro al costruttore e mi aspetto un ArgumentNullException. Ma dal momento che utilizzo il metodo CreateAnonymous dell'Autofixture, ho invece un TargetInvocationException.

Qual è il modo corretto di scrivere questo tipo di test?

public sealed class CreateObject : Command { 
    // Properties 
    public ObjectId[] Ids { get; private set; } 
    public ObjectTypeId ObjectType { get; private set; } 
    public UserId CreatedBy { get; private set; } 

    // Constructor 
    public CreateObject(ObjectId[] ids, ObjectTypeId objectType, UserId createdBy) { 
     Guard.NotNull(ids, "ids"); 
     Guard.NotNull(objectType, "objectType"); 
     Guard.NotNull(createdBy, "createdBy"); 

     Ids = ids; 
     ObjectType = objectType; 
     CreatedBy = createdBy; 
    } 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentNullException))] 
public void constructor_with_null_ids_throw() { 
    fixture.Register<ObjectId[]>(() => null); 
    fixture.CreateAnonymous<CreateObject>(); 
} 

Answer 1

IMO, Ruben Bartelink's comment è la risposta migliore.

Con AutoFixture.Idioms, è possibile fare questo, invece:

var fixture = new Fixture(); 
var assertion = new GuardClauseAssertion(fixture); 
assertion.Verify(typeof(CreateObject).GetConstructors()); 

Il metodo Verify vi fornirà un messaggio molto dettagliato un'eccezione se qualsiasi argomento del costruttore in qualsiasi costruttore manca una clausola Guard.

---

FWIW, AutoFixture utilizza ampiamente riflessione, quindi non mi considero un bug che si getta una TargetInvocationException. Mentre potrebbe scartare tutte le istanze TargetInvocationException e ridisporre le loro proprietà InnerException, ciò significherebbe anche l'eliminazione di informazioni (potenzialmente) preziose (come la traccia dello stack AutoFixture). Ho preso in considerazione questo, ma non voglio prendere AutoFixture in quella direzione, proprio per questo motivo. Un cliente può sempre filtrare le informazioni, ma se le informazioni vengono rimosse prematuramente, nessun cliente può recuperarle.

Se preferite l'altro approccio, non è troppo difficile da scrivere un metodo di supporto che scarta l'eccezione - forse qualcosa di simile:

public Exception Unwrap(this Exception e) 
{ 
    var tie = e as TargetInvocationException; 
    if (tie != null) 
     return tie.InnerException; 
    return e; 
} 

Answer 2

mi sono imbattuto in questo mentre ero alla ricerca di qualcosa di simile. Vorrei aggiungere che, combinato con automoqcustomization e xunit, anche il codice sottostante funziona e risulta molto più pulito.

[Theory, AutoMoqData] 
    public void Constructor_GuardClausesArePresent(GuardClauseAssertion assertion) 
    { 
     assertion.Verify(typeof(foo).GetConstructors()); 
    } 

Hai solo bisogno di creare l'attributo AutoMoqData come segue.

public class AutoMoqDataAttribute : AutoDataAttribute 
    { 
     public AutoMoqDataAttribute() : base(() => new Fixture().Customize(new AutoMoqCustomization())) 
     { 

     } 
    }