Premier TDD, simple projet C# à deux niveaux - Que dois-je tester?

Question

C'est probablement une question stupide mais mon googling ne trouve pas de réponse satisfaisante. Je commence un petit projet en C#, avec juste une couche de gestion et une couche d'accès aux données - étrangement, l'interface viendra plus tard, et j'ai très peu de concept/contrôle sur ce à quoi cela ressemblera.

Je voudrais essayer TDD pour ce projet. J'utilise Visual Studio 2008 (bientôt 2010), ReSharper 5 et nUnit.

Encore une fois, je veux faire du développement piloté par les tests, mais pas nécessairement l'ensemble du système XP. Ma question est: quand et où dois-je écrire le premier test unitaire? Est-ce que je teste uniquement la logique avant de l'écrire ou est-ce que je teste tout? Il semble contre-productif de tester des choses qui n'ont aucune raison d'échouer (auto-propriétés, constructeurs vides) ... mais il semble que la maxime "Pas de nouveau code sans test défaillant" le nécessite. Liens ou références sont bien (mais de préférence aux ressources en ligne, pas de livres - je voudrais commencer dès que possible).

Merci d'avance pour toute indication!

Answer 1

Il semble contre-productif pour tester choses qui ont aucune raison de ne pas (propriétés auto, vides constructeurs) ...

Il est ... Il n'y a aucune logique dans un constructeur vide ou auto-propriété à tester.

Quand est-ce que j'écris le premier test unitaire ?

Avant d'écrire votre première ligne de code testable. Pensez au comportement que vous voulez que votre méthode exécute. Ecrivez votre test en fonction du comportement souhaité. Ce test (et tous les autres qui suivent) concrétisent les spécifications de votre programme. Où dois-je écrire le premier test unitaire?

Dans la première classe de test que vous créez.

Ceci est probablement la meilleure ressource en ligne:

Introduction à une série de tests Design (TDD)
http://www.agiledata.org/essays/tdd.html

Answer 2

Il y a un changement de mentalité que vous devez plonger dans TDD. Si vous ne faites pas de TDD, vous écrivez habituellement du code, puis vous écrivez un test unitaire pour vous assurer que le code répond bien à vos attentes et manipule quelques cas particuliers. Avec TDD, vous écrivez d'abord un test, qui utilise généralement des classes et des méthodes que vous n'avez même pas encore écrites. Une fois que vous avez écrit votre test et que vous êtes satisfait que le test est un bon exemple de la façon dont votre code doit être utilisé, vous commencez à écrire les classes et la méthode pour faire passer le test.C'est un peu dur au début, parce que vous n'aurez pas d'aide intellisense, et votre code ne se construira pas tant que vous n'aurez pas implémenté le code de production, mais en écrivant le test d'abord, vous devrez réfléchir à la façon dont le code sera utilisé avant même que vous l'écrivez.

Answer 3

Il semble contre-productif pour tester choses qui ont aucune raison de ne pas (propriétés auto, vides constructeurs) ...

Il peut sembler contre-productif, mais si vous avez code qui dépend de l'état de defualt de vos objets nouvellement construits, alors il vaut la peine de tester. Quelqu'un peut entrer et modifier les valeurs par défaut pour les champs, et vos sauts de code.

Il peut être utile de garder à l'esprit que vos tests ne servent pas uniquement à détecter les éléments qui échouent, mais à vérifier que votre code respecte le contrat annoncé. Vous pourriez argumenter que vous n'avez pas besoin de vous inquiéter - si le contrat est rompu, le code qui en dépendra sera également brisé. Ceci est vrai, mais crée des tests qui échouent à partir de problèmes "distants". Idéalement, un problème avec une classe devrait provoquer l'échec dans son propre test unitaire, et non dans les tests unitaires de ses clients.

Il est difficile de faire du TDD sans aucune exigence ou conception. Avec le codage traditionnel où vous vous asseyez et créez quelque chose qui correspond à vos attentes, les exigences évoluent au fur et à mesure que le code évolue - les exigences viennent presque du code, vous approfondissez et découvrez plus en détail ce dont vous avez besoin. Mais avec TDD, les tests sont des incarnations des exigences, et donc vous devez les avoir à l'esprit, clair dans votre esprit. Si vous démarrez à partir d'une feuille vide, vous devez procéder à l'analyse des exigences, à la conception des tests et à la conception du code en une fois.

Answer 4

Une façon d'amorcer le TDD est de d'écrire un test d'intégration en premier - c'est-à-dire avant tout test unitaire. Ce test d'intégration vise à prouver que votre application fonctionne comme prévu dans un sens de bout en bout.

Évidemment, l'application n'est pas encore écrite, donc votre test d'intégration initial ne vérifierait pas beaucoup de choses. Par exemple, supposons que vous écriviez un programme de calcul de données censé analyser un fichier plat et produire un rapport de synthèse. Un simple test de bout en bout invoquerait le programme, puis confirmerait qu'un fichier a été produit à l'emplacement prévu. Ce test échouera car votre application ne fait rien pour le moment.

Ensuite, vous écrivez une version minimale de votre application pour satisfaire le test d'intégration simple. Par exemple, l'application s'exécute et écrit un titre codé en dur du rapport de synthèse dans le fichier. Dans sa forme actuelle, votre application est parfois appelée squelette de marche - la tranche la plus fine possible d'une fonctionnalité quelque peu réaliste. A partir de là, vous ajoutez de la viande au squelette - bien sûr, en écrivant un test avant d'écrire chaque nouveau bit de fonctionnalité. Une fois que vous commencez à le faire, la question «Que faut-il tester en premier» devient un peu plus facile et beaucoup de vos nouveaux tests seront axés sur l'unité (plutôt que sur l'intégration).