Développement piloté par les tests avec ASP.NET MVC - par où commencer?

Question

J'ai lu beaucoup de choses sur le développement piloté par les tests (TDD) et je trouve les principes très convaincants, basés sur l'expérience personnelle.

En ce moment, je développe un site web pour un projet de start-up dans lequel je suis impliqué, et je voudrais essayer de mettre en pratique TDD. Donc, je crée une solution vide dans Visual Studio 2010, j'ajoute un projet de site Web ASP.NET MVC et un projet de test. J'ai également ajouté une bibliothèque de classes appelée 'Domain', pour mes objets de domaine, et un projet de test pour cela.

Maintenant, je me demande par où commencer. Dois-je passer un test avant de faire quoi que ce soit? La question est - devrais-je commencer à écrire des tests pour les objets de domaine? Si oui, que devrais-je tester exactement, puisque les objets de domaine n'existent pas encore? Ou devrais-je commencer par le projet de site Web et les tests d'écriture pour cela? Si oui, à quoi dois-je écrire un test? Le contrôleur de la maison/action d'index?

Answer 1

Je commence généralement par la collecte d'un ensemble d'histoires pour l'application que je vais développer. A partir de là, je génère un modèle de domaine, généralement sur "papier". J'organise les histoires que je vais mettre en œuvre et commence à créer le modèle de domaine dans la base de données pour le premier ensemble d'histoires.Une fois que j'ai le DB initial, j'utilise un ORM, dans mon cas, LINQ to SQL, pour mapper les tables de DB sur un ensemble de classes initiales. En général, je ne fais pas l'unité de test du code généré, donc cela me donne une bonne quantité de code pour commencer. Je crée ensuite une méthode stub, qui lance une exception non implémentée, pour implémenter une fonctionnalité de la première classe de domaine avec laquelle je travaille. Typiquement, je commence par la logique de validation. Une fois que vous avez votre méthode de remplacement, vous pouvez utiliser les menus contextuels VS pour créer un ou plusieurs tests unitaires pour cette méthode. Alors vous êtes sur votre chemin. Une fois que j'ai fini avec les objets de domaine pour la première histoire, je commence alors à travailler avec les aspects MVC. D'abord, je vais créer les modèles de vue pour la première vue. Ce sont généralement juste une classe de conteneur vide comme ce point. Ensuite, je vais créer la vue et la taper fortement sur le modèle de vue. Je vais commencer à étoffer la vue en ajoutant des propriétés au modèle de vue selon les besoins de la vue. Notez que puisque le modèle de vue est simplement un conteneur, il n'y a généralement pas de tests unitaires associés. Il sera cependant utilisé dans les tests de contrôleur suivants. Une fois la vue terminée (ou au moins mon concept initial est terminé), je crée ensuite l'action ou les actions du contrôleur stub pour cela, encore une fois la méthode stub renvoie simplement une exception non implémentée. C'est suffisant pour le compiler et laissez-moi utiliser les outils pour créer des tests unitaires pour cela. Je procède au besoin pour tester la (les) méthode (s) et m'assurer qu'elle agit de manière appropriée sur les entrées données et produit un modèle de vue approprié. Si la méthode peut produire plusieurs modèles de vue, c'est-à-dire rendre plusieurs vues, je peux itérer sur le processus de création de modèles de vues/vues/code de contrôleur jusqu'à ce que l'histoire ou les histoires soient terminées. Répétez autant de fois que nécessaire jusqu'à ce que votre ensemble d'histoires soit implémenté, refactoring en cours de route.

Answer 2

Vous pouvez regarder ASP.NET MVC 1.0 Test Driven Development

Answer 3

tests unitaires d'écriture avant même de déclarer la classe que vous testez semble un peu extrême dans une des langues statiques comme C#. Donc, vous commencez par déclarer vos classes de domaine, lancez quelques interfaces qui définissent les opérations que vous allez effectuer sur ces objets de domaine, puis vous ajoutez une classe qui implémentera une interface, en laissant les méthodes lancer NotImplementedException. À ce moment, vous pouvez écrire un test unitaire pour cette classe, car tous les types sont connus. Vous exécutez le test qui échouera, puis vous implémenterez la méthode et relancerez le test - cela passera. Ensuite, vous pouvez refactoriser et optimiser votre implémentation, votre test unitaire doit encore passer. Une fois que vous avez un bon modèle de domaine et une couche d'accès aux données, vous pouvez passer au projet web où vous créez des contrôleurs, en utilisant les interfaces que vous avez précédemment définies (en créant un constructeur qui prend cette interface). Vous écrivez un test unitaire pour ce contrôleur en remplaçant l'interface par un objet simulé, de sorte que vous pouvez tester les actions du contrôleur indépendamment de votre code d'accès aux données.

Et surtout: n'ayez pas peur d'ajouter des classes et des interfaces. J'ai vu des gens écrire d'énormes méthodes qui exécutent plusieurs choses en même temps et qui sont difficiles à tester. Essayez d'isoler différentes tâches dans des méthodes que vous pourriez facilement écrire spécifications pour: quelle sortie vous attendez pour les différentes entrées possibles.

Answer 4

Pour une réponse longue, vous devriez prendre de petites mesures comme ceci.

1) -Premier écrire un test ne

[Test] 
    public void AddSameTag() 
    { 
     UserMovie userMovie = new UserMovie(); 

     userMovie.AddTag("action", "dts", "dts"); 
     Assert.AreEqual(2, userMovie.Tags.Count); 
    } 

2) - Ecrire un code plus simple pour passer le test.

public virtual void AddTag(params string[] tags) 
    { 
     foreach (var text in tags) 
     { 
      Tag tag =new Tag(text.Trim()); 
      if (!movieTags.Contains(tag)) 
       movieTags.Add(tag); 
     } 
    } 

3) - Refactor

. Pour le démarreur ASP.NET MVC et TDD, vous pouvez ignorer le test du contrôleur et vous concentrer sur le domaine par TDD.