Meilleures pratiques de développement piloté par les tests utilisant C # et RhinoMocks

Question

Afin d'aider mon équipe à écrire de code de tests, je suis venu avec cette simple liste des meilleures pratiques pour rendre notre code C# de base plus testable. (Certains des points de référence à des limitations de Rhinocéros se moque, se moquant de cadre pour le C#, mais les règles peuvent s'appliquer de manière plus générale). Quelqu'un aurait-il des pratiques exemplaires qu'ils suivent?

Afin de maximiser la capacité de test de code, suivez ces règles:

1. Écrire le test d'abord, puis le code. Raison: Cela permet d'écrire du code testable et que chaque ligne de code de tests écrits pour elle.

2. Cours de dessin à l'aide de l'injection de dépendance. Raison: Vous ne pouvez pas se moquer ou de tester ce qui ne peut être vu.

3. Séparée code de l'INTERFACE utilisateur à partir de son comportement à l'aide du Modèle-Vue-Contrôleur ou Model-View-Presenter. Raison: Permet à l'entreprise de logique pour être testé pendant que les pièces qui ne peuvent pas être testés (l'INTERFACE utilisateur) est réduit au minimum.

4. Ne pas écrire des méthodes statiques ou des classes. La raison: les méthodes Statiques sont difficiles ou impossibles à isoler et Rhino se moque est incapable de se moquer d'eux.

5. Programme hors les interfaces, et non des classes. La raison: l'Utilisation d'interfaces clarifie les relations entre les objets. Une interface doit définir un service qu'un objet a besoin de son environnement. Aussi, les interfaces peuvent facilement être moqué à l'aide de Rhino se moque et d'autres se moquant de cadres.

6. Isoler les dépendances externes. Raison: non résolus dépendances externes ne peuvent pas être testés.

7. Marque virtuelles, les méthodes que vous avez l'intention de se moquer. Raison: Rhino se moque est incapable de se moquer de non-méthodes virtuelles.

Answer 1

Certainement une bonne liste. Voici quelques pensées sur elle:

Écrire le test d'abord, puis le code.

Je suis d'accord, à un niveau élevé. Mais, je serais plus précis: "Écrire un test abord, puis d'écrire juste assez de code pour passer le test, et répéter." Sinon, j'ai peur que mes tests d'unité ressemblerait plus à de l'intégration ou de tests d'acceptation.

Cours de dessin à l'aide de l'injection de dépendance.

D'accord. Lorsqu'un objet crée ses propres dépendances, vous n'avez aucun contrôle sur eux. L'Inversion de Contrôle / d'Injection de Dépendance que vous donne le contrôle, vous permettant d'isoler l'objet sous test avec des objets fantaisie/talons/etc. C'est une façon de tester les objets dans l'isolement.

Séparée code de l'INTERFACE utilisateur à partir de son comportement à l'aide du Modèle-Vue-Contrôleur ou Model-View-Presenter.

D'accord. Notez que même le présentateur/contrôleur peut être testé à l'aide de DI/Cio, par la remise à un stub/moqué de modèle et de la vue. Découvrez Présentateur Première TDD pour en savoir plus.

Ne pas écrire des méthodes statiques ou des classes.

Pas sûr que je suis d'accord avec celui-ci. Il est possible de l'unité de test d'une méthode statique/classe sans l'aide des simulacres. Donc, c'est peut-être l'un de ces Rhino Mock règles spécifiques que vous avez mentionné.

Programme hors les interfaces, et non des classes.

Je suis d'accord, mais pour une raison légèrement différente. Interfaces offrent une grande souplesse pour le développeur de logiciel - au-delà de l'appui de divers objet fantaisie cadres. Par exemple, il n'est pas possible de soutenir DI correctement sans interfaces.

Isoler les dépendances externes.

D'accord. Masquer les dépendances externes derrière votre façade ou de l'adaptateur (selon le cas) avec une interface. Cela vous permettra de vous isoler de votre logiciel à partir de la dépendance extérieure, un service web, une file d'attente, une base de données ou quelque chose d'autre. Ceci est particulièrement important lorsque votre équipe n'a pas de contrôle de la dépendance (un.k.un. externe).

Marque virtuelles, les méthodes que vous avez l'intention de se moquer.

C'est une limitation de Rhinocéros se moque. Dans un environnement qui préfère main codé des talons plus un objet fantaisie cadre, qui ne serait pas nécessaire.

Et, un couple de nouveaux points à considérer:

L'utilisation de creational les modèles de conception. Cela facilitera la DI, mais il vous permet également d'isoler le code et le tester indépendamment l'un de l'autre logique.

Écrire des tests à l'aide de Bill Sillage de l'Arrangement/Act/Assert technique. Cette technique est très clair quelle configuration est nécessaire, ce qui est actuellement mis à l'épreuve, et ce qui est attendu.

N'ayez pas peur de rouler vos propres objets fantaisie/stubs. Souvent, vous trouverez que l'utilisation de l'objet fantaisie cadres fait vos tests extrêmement difficile à lire. Par roulement de votre propre, vous aurez un contrôle complet sur votre mocks/paie, et vous serez en mesure de garder vos tests lisible. (Voir point précédent.)

Évitez la tentation de revoir la duplication de vos tests unitaires dans les classes de base abstraites, ou de configuration/méthodes de démontage. Faire des cuirs de configuration/code de nettoyage du développeur tente de grok l'unité de test. Dans ce cas, la clarté de chaque test individuel est plus important que le refactoring, la duplication.

Mettre En Œuvre L'Intégration Continue. Check-in de votre code sur chaque "barre verte." Construire votre logiciel et lancez votre suite complète de tests unitaires sur chaque check-in. (Bien sûr, ce n'est pas une pratique de codage, en soi; mais c'est un outil incroyable pour garder votre logiciel propre et entièrement intégré.)

Answer 2

Si vous travaillez avec .Net 3.5, vous voudrez peut-être examiner la bibliothèque moqueuse Moq - elle utilise des arbres d'expression et des lambdas pour supprimer l'idiome non intuitif de réponse à l'enregistrement de la plupart des autres bibliothèques moqueuses.

Consultez ce guide de démarrage rapide pour voir à quel point vos scénarios de test deviennent plus intuitifs. Voici un exemple simple:

 // ShouldExpectMethodCallWithVariable
int value = 5;
var mock = new Mock<IFoo>();

mock.Expect(x => x.Duplicate(value)).Returns(() => value * 2);

Assert.AreEqual(value * 2, mock.Object.Duplicate(value));
 

Answer 3

Connaître la différence entre les faux, les imitations et les moignons et savoir quand les utiliser.

Évitez de trop spécifier les interactions en utilisant des simulacres. Cela rend les tests fragiles .

Answer 4

La vraie raison de la programmation par rapport aux interfaces n’est ne pas à rendre la vie plus facile pour Rhino, mais de clarifier les relations entre les objets dans le code. Une interface doit définir un service qui a besoin d’un objet de son environnement. Une classe fournit une implémentation particulière de ce service. De lecture Rebecca Wirfs-Brock objet livre « Design » sur les rôles, les responsabilités et collaborateurs.