Fermer

février 12, 2020

Faire votre première maquette


Vous cherchez une solution pour accélérer le développement de vos tests unitaires? Ou peut-être voulez-vous écrire des tests unitaires plus stables et plus fiables? Ou vous voulez simplement que les tests unitaires soient isolés de leur environnement? Ensuite, vous avez besoin de JustMock .

Les éléments suivants seront abordés pour vous aider à écrire de meilleurs tests:

  1. Pourquoi se moquer – comment les objets fantaisie vous aident-ils
  2. Exemple du monde réel – un exemple de code à tester
  3. Test de l'exemple – comment utiliser le mocking pour tester l'exemple
  4. Motif AAA – un motif émerge lors de l'écriture de tests propres

Pourquoi se moquer? [19659008] La simulation est un processus utilisé dans les tests unitaires où l'unité testée a des dépendances externes. Le but de la simulation est d'isoler et de se concentrer sur le code testé et non de gérer le comportement ou l'état des dépendances externes telles que la base de données ou le service qui pourraient également casser votre test. En se moquant, les dépendances sont remplacées par des objets de remplacement étroitement contrôlés, comme un objet simulé, qui simulent le comportement des vrais.

L'objet simulé n'est pas simplement un objet avec des valeurs codées en dur à renvoyer. L'objet simulé agit également en tant que collaborateur et est soumis à une modification et à une vérification comportementales dynamiques. Un tel collaborateur vous aidera à atteindre votre objectif de test unitaire souhaité pour un système donné et un ensemble contrôlé d'entrées. Pour ce faire, le simulateur d'objet remplace l'objet réel et renvoie des données ou exécute un comportement que vous avez spécifié.

 WhatIsMock "title =" WhatIsMock "/></p data-recalc-dims=

Pour obtenir un aperçu complet des simulations, un un article informatif intitulé «Les simulacres ne sont pas des talons» de Martin Fowler est à lire absolument.

http://martinfowler.com/articles/mocksArentStubs.html

Après vous avez terminé, il est temps de vous donner une bonne idée de la moquerie avec un exemple du monde réel.

Exemple du monde réel

Je vais implémenter une partie d'un système bancaire. Cela comprend le transfert de fonds entre deux devises différentes

Pour commencer, j'ai créé une interface ICurrencyService : interface

public ICurrencyService

{

décimal [19659019] GetConversionRate ( chaîne fromCurrency, chaîne toCurrency);

}

Cette interface de service sera injectée dans une classe AccountsService qui est responsable de l'opération de transfert de fonds. Une fois les objets de compte source et de destination transmis à l'opération, celle-ci se retirera de la source, convertira la devise en fonction du taux actuel et déposera enfin le montant converti sur le compte cible. Il y aura un contrôle du solde disponible, de l'autorisation, de l'approbation, etc. dans des scénarios plus complexes, mais ils sont hors de portée pour cet article.

public class AccountService: IAccountService

{

privé en lecture seule ICurrencyService currencyService; [19659002]

public AccountService (ICurrencyService currencyService)

{

this .currencyService = currencyService;

}

[19659002] public nul TransferFunds (compte de, compte à, décimal montant)

] {

de. Retrait (montant);

décimal conversionRate = currencyService.GetConversionRate (from.Currency, to.Currency);

décimal convertAmount = montant * conversionRate;

to.Deposit (convertAmount);

}

}

Test de l'exemple

L'objectif est de valider ou d'affirmer l'opération de transfert de fonds entre deux comptes. Par conséquent, c'est le système sous test (SUT), et le service des devises est le collaborateur qui sera moqué. J'utilise JustMock à cet effet, mais le concept de base est le même avec d'autres outils de simulation.

Arrange

Je vais d'abord créer la simulation de l'interface ICurrenyService :

ICurrencyService currencyService = Mock.Create ();

D'après l'implémentation du service de compte, je peux voir que GetCurrencyService est appelé pour récupérer le taux de conversation. L'étape suivante consiste à définir une valeur de retour attendue.

Mock.Arrange (() => currencyService.GetConversionRate ( "GBP" "CAD" ))
.Returns (2,20m) .MustBeCalled ();

Mock.Arrange est le point d'entrée pour définir le comportement attendu pour une maquette donnée. Cette ligne est explicite, mais j'ai utilisé une option supplémentaire: MustBeCalled. Cela garantit que si currencyService.GetConversationRate n'est pas appelé avec les critères ci-dessus, il échouera au test.

Puisque j'ai fini de définir le comportement, je vais alors créer une instance de la Classe AccountService suivie des classes source et destination Account .

var accountService = new AccountService (currencyService);

var canadianAccount = nouveau Compte (0, "CAD" );

var britishAccount = new Account (0, "GBP" );

Act

Next, I ajoutera de l'argent au compte GBP:

britishAccount.Deposit (100);

Transférez-le ensuite sur mon compte canadien:

accountService.TransferFunds (britishAccount, canadianAccount, 100);

Assert

] Une fois le transfert terminé, je dois m'assurer que les opérations se sont déroulées comme prévu. Je vais d'abord affirmer le solde des deux comptes:

Assert.AreEqual (0, britishAccount.Balance);

Assert.AreEqual (220, canadianAccount.Balance);

Ensuite, j'affirmerai la maquette pour vérifier si la méthode requise GetConversationRate est appelée comme prévu:

Mock.Assert (currencyService);

Et voici à quoi ressemble tout le test:

  

[TestMethod]

public nul TestTransferFunds ()

{

// Arranger

ICurrencyService currencyService = Mock.Create ();

Mock.Arrange (() => currencyService.GetConversionRate ( "GBP" "CAD" ))

.Retours (2,20 m) .MustBeCalled ();

var accountService = nouveau AccountService (currencyService);

v ar canadianAccount = nouveau compte (0, "CAD" );

var britishAccount = [19659132] nouveau compte (0, "GBP" );

[19659118] // Loi

britishAccount.Deposit (100);

accountService.TransferFunds (britishAccount, canadianAccount, 100);

// Affirmer

Assert.AreEqual (0, britishAccount.Balance);

Assert.AreEqual (220, canadianAccount.Balance);

Mock.Assert (currencyService);

}

Modèle AAA

Vous pouvez ont remarqué que le test unitaire comportait trois étapes faciles. Cela fait partie d'un modèle bien connu appelé Arrange – Act – Assert ou AAA. La syntaxe de JustMock est implémentée pour suivre strictement le modèle AAA pour vous donner un flux bien structuré, même dans les scénarios les plus complexes.

Dans cet article, j'ai décrit comment la simulation vous aidera. J'ai ensuite construit un exemple de projet et de test pour illustrer comment procéder. La simulation vous aide à écrire des tests unitaires propres et vous permet de vous concentrer sur la logique du test en isolant les facteurs externes. Avec la moquerie, les tests unitaires ne sont plus une corvée.

 JustMock-forum-02-2012





Source link