Les méthodes doivent contenant des expressions LINQ être testé / moquaient?

Question

En supposant que j'ai une classe avec une méthode qui prend un System.Linq.Expressions.Expression comme paramètre, la quantité de valeur dans l'unité test là, il?

public void IList<T> Find(Expression expression)
{
    return someCollection.Where(expression).ToList();
}

tests unitaires ou se moquant de ces sortes de méthodes a été une expérience de l'esprit à la poêle pour moi et je suis maintenant au point où je me demande si c'est tout simplement pas la peine.

Comment puis-je test unitaire cette méthode en utilisant une expression arbitraire comme

List<Animal> = myAnimalRepository.Find(x => x.Species == "Cat");

Answer 1

Il est un peu artificielle unité test, puisque chaque fournisseur de LINQ est mise en œuvre spécifique. Vous pouvez utiliser différentes approches différentes dans votre test, et il tout simplement pas vous dire quoi que ce soit au sujet de la mise en œuvre réelle. Par exemple, si elle est raillé par LINQ à des objets, je pourrais utiliser:

List<Animal> = myAnimalRepository.Find(x => CheckSpecies(x, "Cat"));
...
static bool CheckSpecies(Animal animal, string species) {
    return animal.Species == species;
}

Ce travail de volonté avec LINQ-à-objets ... mais uniquement avec LINQ-à-objets. De même, une utilisation de l'UDF (ou l'une des méthodes d'aide SQL) travailleront dans LINQ to SQL, mais pas Entity Framework.

J'ai arrivé à la conclusion que les tests d'intégration que sont utiles pour ce scénario, donc pas; moqueur est pas très utile ici. Il vous donnera un sentiment heureux chaud que vous avez fait quelque chose d'utile, mais finalement il n'a pas test ce que vous écrivez dans votre application fonctionnera.

Une approche encore mieux, l'OMI, est de ne pas exposer ce sur votre interface référentiel. Si vous limitez les requêtes LINQ à vos données-couche vous supprimez le risque et maintenant vous testez (/ moqueur) une interface pure predicatable.

Je discuterai cette plus .

Answer 2

Pourquoi pas? - Il fait partie de l'interface publique du SUT.

Cela semble facile à tester aussi bien. Je ne généralement, t usage se moque à moins que son absolument nécessaire. Je l'écris test comme

[Test]
public void Find()
{
  var animalRepository = new AnimalRepository();
  animalRepository.Add( dog ); // create a object to species = dog and other relevant attr
  animalRespository.Add( cat ); // etc. etc..

  var results = animalRepository.Find( a => a.Species == "Cat");

  Assert.That( results.Is.EquivalentTo( new List<Animal> { cat } ) );
}

1. Réorganiser: SUT de configuration afin que somecollection interne contient quelques objets connus - par exemple Ajouter (chien); Ajouter (chat); etc.
2. Loi: invoquez la méthode Rechercher une condition
3. Assertion: Assert.That( results.Is.EquivalentTo(expected_results)

Vous pouvez essayer quelques expressions de requête pour faire en sorte que la méthode Find utilise comme une clause Where. Cela devrait le faire.