Test de l'unité, moqueur - cas simple: service - référentiel

Vous pouvez renvoyer une interface au produit au lieu d'un produit en béton.

tel que p> xxx pré>

puis vérifier la propriété propriétaire n'a pas été défini: p>

[Specification]
public class When_product_service_has_get_product_called_with_any_id 
       : ProductServiceSpecification
{
   private int _productId;

   private IProduct _actualProduct;

   [It] 
   public void Should_return_the_expected_product()
   {
     this._actualProduct.Should().Be.EqualTo(Dep<IProduct>());
   }

   [It]
   public void Should_not_have_the_product_modified()
   {
     Dep<IProduct>().AssertWasNotCalled(p => p.Owner = Arg<string>.Is.Anything);

     // or write your own extension method:
     // Dep<IProduct>().AssertNoPropertyOrMethodWasCalled();
   }


   public override void GivenThat()
   {
     var randomGenerator = new RandomGenerator();
     this._productId = randomGenerator.Generate<int>();

     Stub<IProductRepository, IProduct>(r => r.GetProduct(this._productId));
   }

   public override void WhenIRun()
   {
       this._actualProduct = Sut.GetProduct(this._productId);
   }
}

Si vous souhaitez vraiment vous garantir que la méthode de service ne modifie pas les attributs de vos produits, vous avez deux options:

• Définissez les attributs de produit attendus dans votre test et affirmez que le produit résultant correspond à ces valeurs. (Cela semble être ce que vous faites maintenant en clonant l'objet.) P> li>

• Mock le produit strong> et spécifiez les attentes pour vérifier que la méthode de service ne modifie pas ses attributs. P> li> ul>

  C'est comme ça que je ferais ce dernier avec Nmock: P>

  // If you're not a purist, go ahead and verify all the attributes in a single
  // test - Get_Product_Does_Not_Modify_The_Product_Returned_By_The_Repository
  [Test]
  public Get_Product_Does_Not_Modify_Owner() {
  
      Product mockProduct = mockery.NewMock<Product>(MockStyle.Transparent);
  
      Stub.On(_productRepositoryMock)
          .Method("GetProduct")
          .Will(Return.Value(mockProduct);
  
      Expect.Never
            .On(mockProduct)
            .SetProperty("Owner");
  
      _productService.GetProduct(0);
  
      mockery.VerifyAllExpectationsHaveBeenMet();
  }
  

Mes stands de réponse précédente, bien qu'il suppose que les membres de la classe de produits que vous vous souciez sont publics et virtuels. Ceci n'est pas probable si la classe est un poco / dto.

Ce que vous recherchez peut être reproché comme un moyen de comparer les valeurs (non pas d'instance) de l'objet. P>

un façon de comparer pour voir s'ils correspondent lorsqu'ils sont sérialisés. Je l'ai fait récemment pour certains code ... remplaçait une liste de paramètres longue avec un objet paramétré. Le code est CRUFTY, je ne veux pas le refroidir comme ça comme ça va bientôt de toute façon. Donc, je viens de faire cette comparaison de sérialisation comme un moyen rapide de voir s'ils ont la même valeur. P>

J'ai écrit des fonctions utilitaires ... ASSERT2.issamevalue (attendu, réel) qui fonctionne comme celle de Nunit. ASSERT.AREEQUAL (), sauf que cela serifie via JSON avant de comparer. De même, it2.issamesérialisalisé () peut être utilisé pour décrire les paramètres transmis à des appels moqués de manière similaire à Moq.it.is (). P>

public class Assert2
{
    public static void IsSameValue(object expectedValue, object actualValue) {

        JavaScriptSerializer serializer = new JavaScriptSerializer();

        var expectedJSON = serializer.Serialize(expectedValue);
        var actualJSON = serializer.Serialize(actualValue);

        Assert.AreEqual(expectedJSON, actualJSON);
    }
}

public static class It2
{
    public static T IsSameSerialized<T>(T expectedRecord) {

        JavaScriptSerializer serializer = new JavaScriptSerializer();

        string expectedJSON = serializer.Serialize(expectedRecord);

        return Match<T>.Create(delegate(T actual) {

            string actualJSON = serializer.Serialize(actual);

            return expectedJSON == actualJSON;
        });
    }
}

Si tous les consommateurs de produitsService.getProduct () attendent le même résultat que s'ils l'avaient demandé au producteur, pourquoi ne veulent-ils pas appeler productrexitory.getProduct () lui-même? Il semble que vous ayez un Middle Man ici.

Il n'y a pas beaucoup de valeur ajoutée à Produitservice.getProduct (). Dump it et que les objets client appellent le produit producteur.getProduct () directement () directement. Mettez la gestion des erreurs et de vous connecter à ProductrePository.getProduct () ou du code de consommateur (éventuellement via AOP).

Pas plus de milieu, pas plus de problème de divergence, plus besoin de tester cette divergence.

laissez-moi indiquer le problème comme je le vois.

1. Vous avez une méthode et une méthode de test. La méthode de test valide la méthode d'origine.
2. Vous modifiez le système sous test en modifiant les données. Ce que vous voulez voir, c'est que le même test d'unité échoue.

   Donc, en effet, vous créez un test qui vérifie que les données de la source de données correspondent aux données de votre objet récupéré une fois la couche de service le renvoie. Qui tombe probablement sous la classe de "test d'intégration".

   Vous n'avez pas beaucoup d'options de bonnes options dans ce cas. En fin de compte, vous voulez savoir que chaque propriété est la même que de la valeur de la propriété passée. Donc, vous êtes obligé de tester chaque propriété de manière indépendante. Vous pouvez le faire avec une réflexion, mais cela ne fonctionnera pas bien pour les collections imbriquées.

   Je pense que la vraie question est la suivante: pourquoi tester votre modèle de service pour l'exactitude de votre couche de données et pourquoi écrivez le code dans votre modèle de service pour casser le test? Êtes-vous inquiet que vous ou d'autres utilisateurs puisse définir des objets sur des états non valides de votre couche de service? Dans ce cas, vous devriez changer votre contrat afin que le produit.OWNER soit loadonly .

   Vous feriez mieux d'écrire un test sur votre couche de données afin de vous assurer qu'il récupère correctement les données, puis utilisez des tests d'unité pour vérifier la logique commerciale dans votre couche de service. Si vous êtes intéressé à plus de détails sur cette approche, répondre dans les commentaires.