Utile modèles de conception pour les tests unitaires/TDD?

Ici Mike Clifton décrit les 24 modèles de test à partir de 2004. Ses une heuristique utile lors de la conception des tests unitaires.

http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns

De Réussite/D'Échec Des Modèles

Ces modèles sont votre première ligne de défense (ou d'attaque, selon votre point de vue) pour garantir le bon code. Mais attention, elles sont trompeuses en ce qu'ils vous disent au sujet du code.

• Le Simple Motif De Test
• Le Code-Parcours
• Le Paramètre De Gamme Modèle

De Données Les Modèles De Transaction

De données les modèles de transaction sont un point de départ à embrasser les enjeux de la persistance des données et de la communication. Plus sur ce sujet est abordé sous "Modèles de Simulation". Aussi, ces modèles délibérément omettre les tests de stress, par exemple, le chargement sur le serveur. Cette question sera examinée sous "Stress-Test des Modèles".

• Le Simple-Données-Modèle D'E/S
• La Contrainte-Le Modèle De Données
• La Restauration Motif

Collection Sur Les Modes De Gestion

Beaucoup de ce que les applications de faire, c'est gérer des collections d'informations. Bien qu'il existe une variété de collections à la disposition du programmeur, il est important de vérifier (et donc le document) que le code est à l'aide de la bonne collection. Cette touche de commande et de contraintes.

• La Collection-Modèle De Commande
• L'Énumération Modèle De La
• Collection Contrainte Du Modèle
• La Collection D'Indexation De Modèle

Schémas De

Unité de test ne doit pas être concerné par la fonction, mais aussi de la forme. Comment efficacement le code sous test effectuer sa fonction? À quelle vitesse? De combien de mémoire faut-il utiliser? Est-il compromis d'insertion de données pour l'extraction des données de manière efficace? Est-il libérer les ressources correctement? Ce sont toutes les choses qui sont du ressort de l'unité de test. En incluant les performances des modèles dans l'unité de test, l'opérateur a un but à atteindre, ce qui résulte en un code de meilleure qualité, une meilleure application, et le bonheur de la clientèle.

• La Performance Motif De Test

Processus De Modèles

Unité de test est destiné à tester, eh bien, unités...les fonctions de base de l'application. Il peut être soutenu que les processus de test devrait être relégué à l'acceptation des procédures de test, cependant je n'achète pas dans cet argument. Un processus est juste un autre type d'unité. Les processus de test avec un testeur unitaire de fournir les mêmes avantages que les autres tests unitaires--il des documents de la manière dont le processus est destiné à travailler et l'unité testeur peut aider le responsable de l'implémentation par aussi de tester le processus de séquence, d'identifier rapidement les éventuels problèmes de l'interface utilisateur ainsi. Le terme "processus" comprend également les transitions de l'état et des règles de gestion, qui doit être validée.

• Le Processus De Séquence Motif
• Le Processus De L'État-Patron
• Le Processus De La Règle De Modèle

Modèles De Simulation

Des transactions de données sont difficiles à tester, car ils ont souvent besoin d'une configuration prédéfinie, une connexion ouverte, et/ou en ligne de l'appareil (pour n'en nommer que quelques-uns). Les objets fantaisie peut venir à la rescousse par la simulation de la base de données, des services web, l'utilisateur, la connexion et/ou de matériel avec lequel le code est concluant. Les objets fantaisie ont également la capacité de créer des conditions d'échec qui sont très difficiles à reproduire dans le monde réel--une perte de connexion, un serveur lent, l'échec d'un concentrateur de réseau, etc.

• Maquette De L'Objet Modèle
• Le Service De Simulation De Modèle
• L'Erreur Sur Les Bits De Simulation De Modèle
• Le Composant De Simulation De Modèle

Multithreading Modèles

Tests unitaires des applications multithread est probablement l'une des choses les plus difficiles à faire parce que vous avez à mettre en place une condition qui, par sa nature, est destiné à être asynchrone et donc non-déterministe. Cette rubrique est probablement un article en lui-même, donc je vais en donner un très générique modèle ici. En outre, pour effectuer de nombreuses opérations de filetage tests correctement, l'unité de testeur de l'application doit lui-même d'exécuter des tests comme des threads séparés de sorte que l'appareil testeur n'est pas désactivé lorsqu'un thread se termine dans un état d'attente

• L'A Signalé Modèle
• De L'Impasse-De La Résolution Du Motif

De Stress-Test Des Modèles

La plupart des applications sont testées dans des environnements idéaux--le programmeur est à l'aide d'une machine rapide avec peu de trafic réseau, à l'aide de petits jeux de données. Le monde réel est très différent. Avant de quelque chose de complètement pauses, l'application peut souffrir de la dégradation et répondent mal ou avec des erreurs de l'utilisateur. Unité de tests visant à vérifier que le code de la performance sous stress devraient être satisfaits avec une égale ferveur (si pas plus) que les tests unitaires dans un environnement idéal.

• La Masse De Données-Stress Motif De Test
• La Ressource-Stress Motif De Test
• Le Chargement Motif De Test

Couche De Présentation Des Modèles

L'un des aspects les plus difficiles de l'unité de test est de vérifier que l'information est d'entrer dans le droit de l'utilisateur à la couche de présentation elle-même et que le fonctionnement interne de l'application sont correctement réglage de la couche de présentation de l'état. Souvent, les couches de présentation sont mêlés à des affaires objets, des objets de données, et la logique de contrôle. Si vous avez l'intention de l'unité de test de la couche de présentation, vous vous rendez compte que la séparation des préoccupations est obligatoire. Une partie de la solution consiste à développer un Modèle-Vue-Contrôleur (MVC) de l'architecture. L'architecture MVC fournit un moyen de développer de bonnes pratiques de conception lorsque vous travaillez avec la couche de présentation. Toutefois, il est facile d'abus. Une certaine discipline est nécessaire pour s'assurer que vous êtes, en fait, la mise en œuvre de l'architecture MVC correctement, plutôt que de simplement en parole seulement.

• Le Point De Vue De L'État-Modèle De Test
• Le Modèle De L'État-Modèle De Test

Michael Plume du livre Travailler Efficacement Avec Le Code Existant est exactement ce que vous cherchez. Il définit legacy code "code sans tests" et parle de la façon de l'obtenir en vertu de test.

Comme avec la plupart des choses, c'est une étape à la fois. Lorsque vous apportez une modification ou une correction d'essayer d'augmenter la couverture de test. Comme le temps passe, vous aurez un ensemble plus complet de tests. Il parle de techniques de réduction de couplage et comment le test d'ajustement de pièces entre la logique de l'application.

Comme indiqué dans d'autres réponses de l'injection de dépendances est un bon moyen d'écrire vérifiables (et faiblement couplés en général) du code.

Organiser, d'Agir, de faire Valoir est un bon exemple d'un modèle qui vous aide à structurer votre code de test autour notamment des cas d'utilisation.

Voici quelques hypothétique de code C# qui illustre le schéma.

[TestFixture]
public class TestSomeUseCases() {

    //Service we want to test
    private TestableServiceImplementation service;

    //IoC-injected mock of service that's needed for TestableServiceImplementation
    private Mock<ISomeService> dependencyMock;

    public void Arrange() {
        //Create a mock of auxiliary service
        dependencyMock = new Mock<ISomeService>();
        dependencyMock.Setup(s => s.GetFirstNumber(It.IsAny<int>)).Return(1);

        //Create a tested service and inject the mock instance
        service = new TestableServiceImplementation(dependencyMock.Object);
    }

    public void Act() {
        service.ProcessFirstNumber();
    }

    [SetUp]
    public void Setup() {
        Arrange();
        Act();
    }

    [Test]
    public void Assert_That_First_Number_Was_Processed() {
        dependencyMock.Verify(d => d.GetFirstNumber(It.IsAny<int>()), Times.Exactly(1));
    }
}

Si vous avez beaucoup de scénarios de test, vous pouvez extraire une classe abstraite commune avec le béton Organiser & Loi sur les bits (ou tout simplement Organiser et mettre en œuvre le reste abstrait bits & fonctions de test dans les classes héritées de ce groupe de fonctions de test.

Modèles de conception ne sont pas directement pertinentes pour les ATS, car ils sont des détails de mise en œuvre. Vous ne devriez pas essayer de s'adapter à des modèles dans votre code, simplement parce qu'ils existent, mais ils ont plutôt tendance à apparaître comme votre code évolue. Ils deviennent également utile si votre code est puant, car ils aident à résoudre de tels problèmes. Ne pas développer du code avec des modèles de conception dans l'esprit, il suffit d'écrire le code. Ensuite d'obtenir des tests de passage, et refactoriser.

De L'Injection De Dépendances/Cio. Lire également sur l'injection de dépendance des frameworks tels que SpringFramework et google guice. Ils sont également la cible des comment écrire du code testable.