Démarrage d'un nouveau projet avec TDD

J'étudie TDD et j'ai lu que cela vous aide également à définir la conception de l'application, n'est-ce pas?

J'ai donc décidé de commencer à créer un nouveau projet pour m'aider à mieux le comprendre.

Je veux créer un système d'enregistrement d'utilisateur simple qui demandera son nom, son adresse e-mail, son pays (en choisira un dans une liste) et son numéro de téléphone.

La question est donc ...

J'ai créé une nouvelle solution dans VS 2010, ajouté un nouveau projet de test et je ne sais pas quels tests écrire!

Puisqu'il m'aidera à définir la conception, quels tests pourrais-je écrire ici?

Merci pour toute aide!

Lorsque vous écrivez des tests unitaires, vous testez le comportement de votre application, donc la question importante à vous poser est de savoir ce que fait votre application ? Voici un début:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

La simple création d'un projet de test et l'écriture de certaines méthodes de test est une sorte de TDD, mais d'après mon expérience, cela n'aide pas beaucoup sauf si vous travaillez sur une bibliothèque où il existe une API connue et les appels de méthode correspondent directement à quelque chose attendu par l'utilisateur . Vous devez trouver la bonne liste de tests, et pour une application non triviale, cela peut être très difficile à faire.

Je recommande d'essayer SpecFlow - il continue de définir des tests bien séparés de l'implémentation et la structure des fichiers de fonctionnalités vous oblige à réfléchir à ce que vous testez réellement.

Lorsque vous définissez une fonctionnalité, vous écrivez simplement quelque chose comme

When a user is saved
Then the user should exist

Comme vous n'êtes pas dans un fichier de code à ce stade, vous n'êtes pas tenté de penser aux détails de l'implémentation, comme la méthode qui est appelée pour créer un utilisateur ou même la classe dans laquelle il est implémenté. Vous pouvez utiliser des balises pour choisir différentes implémentations, à ce niveau, peu importe que "l'utilisateur soit enregistré" signifie un appel à CreateUser ou l'ouverture d'un navigateur et l'envoi d'un formulaire.

Une fois que vous avez défini les fonctionnalités, tous les tests sont générés et commenceront à passer à mesure que vous implémentez les définitions d'étape et le code d'application réel testé.

Pour une application simple, vous pouvez simplement créer les fichiers de fonctionnalités, mais pour tout ce qui est plus complexe, il est utile de rassembler au préalable une spécification plus complète. J'utilise une application de mindmapping iPad pour cela, mais vous pouvez utiliser l'outil avec lequel vous êtes le plus à l'aise.

Commencez avec une liste de fonctionnalités de haut niveau telles que "Enregistrement d'utilisateur". Celles-ci ont tendance à être trop larges pour écrire des tests directement, alors décomposez-les en sous-fonctionnalités qui peuvent être clairement définies et généralement mappées à une action utilisateur spécifique comme "Enregistrer l'utilisateur" ou "Afficher l'utilisateur existant".

Chacune de ces sous-fonctionnalités aura besoin d'une liste de scénarios qui, ensemble, définissent complètement si la fonctionnalité fonctionne ou non, des choses comme "Peut enregistrer un utilisateur valide" et "Ne peut pas enregistrer un utilisateur avec un nom d'utilisateur en double".

Au fur et à mesure que vous construisez cette liste, il deviendra généralement clair où la structure doit être ajustée - si vous ne pouvez pas proposer de tests de scénario pour une fonctionnalité, ou si vous vous retrouvez avec trop de fonctionnalités dans une fonctionnalité, cette fonctionnalité est probablement définie à le mauvais niveau et doit être divisé ou modifié.

J'ai trouvé bon de sauvegarder mes premières expériences dans TDD avec de la lecture et de la découpe de code. L' article de wikipedia sur le sujet est très bon et vous mènera à une grande variété d'autres ressources. Cherchez les choses de Kent Beck en particulier - une sorte de père de TDD.

Une autre chose qui pourrait vous aider à vous lancer est de faire des katas - des exercices d'entraînement simples et presque stupides. Roy Osherove en a de bons.

Au-delà de cela, gardez à l'esprit les idées clés du TDD - écrivez un test à la fois et ne continuez pas tant que tous les tests précédents n'ont pas réussi. N'écrivez que suffisamment de code pour satisfaire le test en cours, évitez la tentation d'en écrire plus. Au fur et à mesure, arrêtez-vous de temps en temps et pensez si vous pouvez nettoyer le code ou les tests. Développer toujours dans un cycle de refactorisation rouge (échec), vert (réussite), refactor.

Et pour vous aider à démarrer, commencez peut-être par votre nom. De quoi vas-tu avoir besoin?

Vous aurez probablement besoin d'un cours. Écrivez un test pour cela (certaines personnes sautent cela mais au début faites-le pour l'exercice) et écrivez la classe.

Ensuite, votre classe devra enregistrer un nom. Écrivez un test prouvant que votre classe le peut. Ensuite, écrivez à nouveau du code pour réussir le test.

Ensuite, vous avez peut-être d'autres règles commerciales. Vous souhaitez peut-être que votre nom contienne un nombre minimum de caractères. Écrivez le test, voyez-le échouer, écrivez le code.

Etc...

Je pense qu'il n'est pas possible de vous donner l'idée de TDD dans une réponse courte. Vous avez besoin de "voir" le sombody en train de le pratiquer, pour en avoir la sensation. La meilleure ressource que j'ai jamais trouvée à ce sujet est http://pragprog.com/titles/achbd/the-rspec-book . Avant de me dire que Ruby n'est pas votre langue: lisez la préface d'oncle Bob! ;-)

Vous voudrez peut-être configurer un test qui essaie d'ajouter plusieurs valeurs différentes dans le champ e-mail, certaines étant valides et d'autres non. N'arrêtez pas de développer jusqu'à ce que tous les tests donnent la valeur attendue. Des trucs comme ça.

Comme vous avez décrit le système, il n'y a qu'un seul test au niveau de l'application:

[Test] public void Save_and_retrieve_user (String name, String email, ...) {// Save // ​​Retrieve // ​​Verify}

Au fur et à mesure que vous affinez les exigences, ajoutez d'autres tests.