J'ai fait un certain nombre de tests pour développer l'utilisation de TDD; c'est-à-dire que vous écrivez d'abord mon test.
J'ai toujours été utilisé pour écrire le test comme, à l'aide de cette convention de dénomination. P>
"As a user, I can return the total number of records in the database"
4 Réponses :
Compte tenu de votre histoire d'utilisation, mes noms de test seraient quelque chose comme:
Et la classe de test serait quelque chose comme DatabaserecordCounterTest.
Il existe de nombreuses approches pour tester la nommage, celle que vous avez mentionnée en être l'un d'entre eux. Le préfixe avec le nom de la méthode est bon (et adapté à la plupart des cas), mais vous pourriez rencontrer des problèmes mineurs lorsque votre test de l'unité s'étend sur plusieurs méthodes (c'est-à-dire commun add-supprimer ou add-recherche combinaisons ).
Avec TDD, vous devriez commencer par l'histoire de l'utilisateur (comme vous le faites maintenant) et nommez votre test en conséquence. Seulement alors vous allez à la mise en œuvre. Avec TDD, vos noms de méthodes seront pilotés par des tests.
Aussi une fois que j'ai écrit mes tests et mes méthodes / classes et tout fonctionne, il est logique de créer des "tests de l'unité" supplémentaires pour tester la classe pour que je n'ai pas via TDD?
Il ne devrait pas y avoir une seule chose que vous ne faites pas via TDD. C'est tout le point - vous lecteur votre conception et votre implémentation via tests. Vous n'écrivez pas une seule ligne de code qui ne serait pas originaire d'un test d'échec.
J'aime utiliser deux méthodes que j'ai volées de Phil HAACK et Erik Dietrich
Il existe fondamentalement une classe de base qui définit la classe testée, puis des classes héritées nommées d'après le comportement qu'ils vont tester. Les tests sont ensuite ajoutés avec des noms verboses. P>
public class TestClassUnderTest
{
public ClassUnderTest Target { get; set; }
[SetUp]
public void before_each_test()
{
Target = new ClassUnderTest();
}
// Now each behavior has its own class with the system under test available through the Target property
public class ThisMethod : TestClassUnderTest
{
[Test]
[ExpectedException(typeof(Exception))]
public void throws_if_null_is_passed()
{
Assert.IsTrue(false); // make it fail at first
}
[Test]
public void returns_true_if_string_is_empty()
{
Assert.IsTrue(false); // make it fail at first
}
}
public class ThatMethod : TestClassUnderTest
{
[Test]
public void returns_argument_concatenated_with_timestamp()
{
Assert.IsTrue(false); // make it fail at first
}
}
}
En suivant une approche de développement "hors-in", vous découvrirez / évolueriez vos noms de test de l'unité TDD dans le cadre du processus de développement (voir également cette réponse ici )
Par exemple, prenez votre histoire d'utilisateur (je l'ai légèrement modifiée): Lorsque vous développez cette histoire, vous cassez C'est dans un certain nombre de scénarios, par exemple à ce stade, vous ne savez toujours pas quels tests unitaires dont vous auriez besoin. Cependant, en utilisant l'approche de développement "extérieur", vous revenez maintenant aux techniques TDD pour mettre en œuvre les fonctionnalités nécessaires. Par exemple, vous impliqueriez ensuite l'installation de connexion à l'aide de votre approche TDD normale. Par conséquent, vous pourriez avoir une méthode d'essai appelée: Vous pouvez également "simuler jusqu'à ce que vous le faisiez" à l'aide de cette approche, c'est-à-dire que vous pouvez vous moquer de certaines dépendances (par exemple, le mécanisme d'autorisation) Pour que vous puissiez vous concentrer sur la mise en œuvre des principales caractéristiques du scénario. SUIVANT que cette approche développerait progressivement toutes les fonctionnalités requises pour votre histoire d'utilisation tout en créant les tests d'unité exacts pour satisfaire les scénarios. < / p>
Est-ce que l'une de ces réponses a aidé? Avez-vous trouvé une résolution à votre problème?