Disons que je commence à faire une partie avec TDD. Est-ce un bon premier test?
[TestMethod]
public void Can_Start_And_End_Game()
{
Tetris tetris = new Tetris();
tetris.Start();
tetris.End();
}
6 Réponses :
Je pense que le but du test peut être plus clair en attirant toutes les exceptions et en défaillant explicitement le test s'il utilise:
Il y a un assert.doesnotterthrow méthode qui fait cela.
N'est-ce pas redondant comme dit "let x = x" ou "si (vrai == vrai)"? Je pensais que c'était une convention de Xunit que l'idée "Notththrow" est toujours implicite et comprise, avec ou sans assertion de quelque nature que ce soit, quel que soit le nom de la méthode.
Je ne suis pas un grand fan de ce test. Oui, cela a aidé à définir l'interface, mais il n'est pas très fort pour la définition du comportement (et des tests).
Je pense qu'il serait peut-être préférable d'avoir un test qui gère le démarrage. Cela affirmerait probablement les paramètres par défaut ou les valeurs de notation. Ensuite, j'aurais des tests supplémentaires pour voir si vous pouvez mettre fin à une partie.
Idéalement, chaque méthode d'essai exécute un comportement.
+1. Un bon test a une seule assertion dedans; celui-ci n'a pas.
Oui, le test confirme qu'aucune exception n'est lancée dans le constructeur, le Je vois peu de valeur dans un bloc d'essai / attraper supplémentaire dans le test pour attraper des exceptions. L'outil exécutant le test attrapera et signalera ceux-ci. Utilisation du principe TSTTCPW Le test peut passer sans le bloc Type / Catch.
Vous pouvez faire le test un peu plus significatif en ajoutant des affirmations à la fin, par exemple validant la valeur des propriétés sur l'objet Veuillez être conscient de la différence entre écrire un test d'unité et utiliser TDD. La valeur vient de comprendre cette différence. start () et la méthode stop ()
Tetris .
Vous ne conduisez pas vraiment le développement de la classe Tetris avec ce test - vous avez décidé de ce que son API devrait être, ce qui va bien, mais pourquoi ne pas écrire un test qui teste quelque chose qu'il devrait réellement faire?
Les tests doivent informer l'API, pas vice versa (IMHO).
Je pense que tu le cloués. Mais jetez également un coup d'œil à la réponse de S. Lott.
@Devourded - merci. Je préfère en fait S. Lott's :)
Cela me force essentiellement à définir 3 choses: la classe Tetris et ses méthodes de début () et de fin (),
vrai.
mais en plus de cela, c'est assez inutile.
faux.
Plus tard, il ne servira probablement aucune sorte de but
faux, aussi.
Son ... but [est de] montrer qu'il doit être possible de commencer une partie et de la mettre fin à une exception au milieu
Et c'est énorme. Épique. Monumental.
En effet, ce test échouera si souvent que vous grandirez de le détester. Chaque exception sans heurt et non capturée de toutes sortes d'endroits aléatoires de votre programme échouera ce test. Vous construirez une journalisation et un débogage minutieux en raison de ce test.
Ce test est épique.
Wow, je n'avais pas pensé à cela.
J'ai toujours su que j'étais un génie de la programmation. Maintenant, j'ai la preuve.
@Devourded Elysium: Désolé, vous n'êtes pas un génie. Vous suivez simplement ce que le génie vous a dit de faire. La bonne nouvelle est que vous suivez des génies.
Comme S. Lott dit, ce test couvre une tonne de terrain. C'est tellement "la peine" que cela vaut la peine de se casser dans au moins 3 tests et d'ajouter des affirmations appropriées à chacun:
En Java, les méthodes ne sont pas capitalisées. Par conséquent
tetris.start () ettetris.end ()Techniquement, c'est un test d'intégration car vous testez plus d'une chose. Vous devriez avoir des tests pour commencer, tests pour la fin et ce test d'intégration.