IList paramètre constructeur et AutoFixture

Question

Utilisation autofixture , je suis en train de construire par exemple anonyme Project:

 _f=new Fixture().Customize(new AutoMoqCustomization());
 _p=_f.CreateAnonymous<Project>();

Cela échoue, la cause exige constructeur public Project IList<Partner>

public Project(/*.....*/,IList<Partner> partners){
  Guard.AgainstEmpty(partners);
}

trace de pile n'est pas significative (au moins - pour moi). Juste une réflexion yada-yada:

  

a échoué: System.Reflection.TargetInvocationException: Exception a été levée par la cible d'un appel
.   ---- System.ArgumentException: La valeur ne tombe pas dans la fourchette prévue
.       à System.RuntimeMethodHandle._InvokeConstructor (méthode IRuntimeMethodInfo, Object [] args, SignatureStruct & signature, RuntimeType DeclaringType)

- comment faire passses sûr de autoFixture dans la collecte anonyme de partenaires afin de construire

---

Il est pas faute de IList<Partners>. Il y a un autre paramètre appelé Priority. Priority détient elle-même Measure, Measure détient IList<Indicator> et appelle Guard.AgainstEmpty(indicators) dans le constructeur.

Il ressemble à ceci:

fixture.CreateAnonymous<Foo>(); //kaboom!
public class Foo{
  public Foo(IList<Bar> bars){
    Guard.AgainstEmpty(bars); //just checks count for ienumerable & throws if 0
    Bars=bars;
  }
  public IList<Bar> Bars {get;private set;} //should be readonly collection...
}

public class Fizz{
  public Fizz(Foo foo){
    Foo=foo;
  }
  public Foo{get;private set;}
}

public class Bar{}

Construction échoue dans la méthode de Guard.AgainstEmpty. Donc - la question devient - comment faire AutoFixture vous remplit quelques bars dans la collection de barres avant la construction foos

Answer 1

Cela aide. Parcourir la source aide souvent .

var indicators=_f.CreateMany<Indicator>();
_f.Register<IList<Indicator>>(()=>indicators.ToList());

Il est peut-être mieux si.

---

Dans l'ensemble, c'est la façon dont il regarde le moment:

  _f=new Fixture().Customize(new AutoMoqCustomization());
  var indicators=_f.CreateMany<Indicator>();
  _f.Register<IList<Indicator>>(()=>indicators.ToList());
  var regionName=_f.CreateAnonymous<string>();
  _f.Register<string,Country,bool,Region>((name,country,call)=>
    new Region(regionName,_f.CreateAnonymous<Country>(),true));
  _c.Set(x=>x.Regions,_f.CreateMany<Region>().ToList());
  _f.Register<IList<ManagementBoardEntry>>(()=>
    _f.CreateMany<ManagementBoardEntry>().ToList());
  _f.Register<IList<FinancialInfoEntry>>(()=>
    _f.CreateMany<FinancialInfoEntry>().ToList());
  _f.Register<IList<Partner>>(()=>_f.CreateMany<Partner>().ToList());
  _p=_f.CreateAnonymous<Project>();

Impossible d'appeler cette belle (toutes les suggestions sont les bienvenus refactoring), mais il est encore beaucoup mieux que d'écrire tout manuellement.

---

Utilisation IList il y a un mauvais choix pour vous. Pire encore - J'utilise IList pour des propriétés aussi. Ce client de les utiliser invite directement au lieu de passer par la racine globale.

Il y a un inconvénient lors de l'utilisation params. Ne peut pas utiliser plus d'un (à moins que je manque quelques notions de base à nouveau). Et je reçois la liste comme une entrée (une partie de DOM feuille Excel), ne peut pas savoir comment les éléments compilation beaucoup seront là.

Le modèle est vraiment frais. Juste cuire au four (donc il y a une grande chance que je me trompe au sujet de ces contrôles de vide, parlera avec le client et analyste d'affaires à ce sujet).

Ma stratégie est de sculpture librement et le pousser vers l'état désiré avec les tests unitaires. Ceci est la raison réelle Je n'aime pas peu stricte TDD a. Il vole point, me force à penser à des détails au lieu de l'image tout un peu trop tôt. Je préfère esquisser et affiner jusqu'à ce qu'il semble bon. Mais cela pourrait être parce que je ne suis pas assez fluide avec le test.

Quoi qu'il en soit - merci pour de bons conseils. Je vais continuer à en apprendre davantage sur AutoFixture.