IDE ECLIPSE - test JUnit un développement clé pour Java Agile Software (Partie II)


Notre dernière leçon a fini avec la silhouette d'un programme de test JUnit ayant été construit et les tests JUnit. Bien sûr, comme indiqué à la fin du tutoriel tout test de faild parce que le programme stub qui a créé la preuve ne était qu'un talon et chacune des trois méthodes de tests JUnit eu une instruction assert qui a présenté le message sortant, «pas encore mis en œuvre ! "

Dans ce tutoriel, nous allons prendre le tutoriel où nous en étions et commencer à coder, qui permettra de tester les trois méthodes:




  • le fabricant testBillingAddress
  • le procédé testSetCity
  • le procédé testZipCode

Comme mentionné précédemment, le code de la billingAddress de classe se trouve dans l'annexe à la fin du tutoriel.

Commençons donc!

,

Le cas de test JUnit État à la fin de la leçon précédente

Préliminaires et création d'un test pour la première méthode

Si vous avez suivi le long et le codage lorsque vous redémarrez Eclipse, vous devriez voir le code de test affiché comme indiqué dans l'instantané précédent. Si vous avez exploré sur leurs fonctions, la fenêtre peut se afficher différemment. Dans ce cas, aller à Fenêtre> Ouvrir Perspecitive> Java Perspective. Si nécessaire, utilisez l'Explorateur de projet pour ouvrir le programme de test.

Maintenant, nous allons commencer codant pour la méthode d'essai de construction billingAddress. Donc, nous allons voir ce que le fabricant aurait à faire.

// Constructeur

billingAddress publique () {
companyName = "blank";
streetAddress = "blank";
city ​​= "blank";
Etat = "blank";
Code Postal = 00000;
}

Le fabricant dispose de 5 champs. Quatre d'entre eux sont fixés à la parole vide, et le cinquième, le zipCode est réglé à zéro.

Ainsi, les étapes sont les suivantes:

  • Créer un nouvel objet billingAddress
  • La preuve que les champs de l'objet sont correctement définies.

La première ligne, nous avons vu plus tôt:

BillingAddress billingAddress BA1 = new ();

La ligne suivante est nouvelle. La méthode est nouvelle assertEquals. E 'une partie de l'ensemble des tests JUnit. Les valeurs indiquées pour le procédé sont la valeur prévue et la valeur réelle. Dans ce cas, la valeur attendue, la valeur définie dans le constructeur était le mot blank.For la valeur réelle qui est obtenu en utilisant la méthode de l'getBillingAddress BA1 objet.

Pour souligner ce point, le modèle pour assertEquals est:

assertEquals (valeur attendue, valeur);

et de notre déclaration est faite:

assertEquals ("blanc", ba1.getCompanyName ());

Cette déclaration est répétée pour les trois prochaines domaines de billingAddress, BA1, en remplaçant «getter" approprié pour chaque.

La dernière déclaration du cas de test est légèrement différent que le champ de zipCode est un entier.

Le code pour la billingAddress constructeur

plus d'explications sur assertEquals mehod

Il existe une différence entre assertEquals et la méthode que nous avons observé jusqu'à présent.

Dans le cas de la méthode getCity nous avions à faire ce qui suit

  • nous avons dû créer un objet de type billingAddress, et
  • référence à la méthode par quaified nom de opject créé comme ba1.getCity ().

Pourquoi avons-nous pas?

Batte BillingAddressTest BillingAddressTest = new ();

bat.assertEquals (......

Ce est parce que assertEquals est un méthode statique.


méthode statique est:

  • un procédé qui appartient à la catégorie dans son ensemble.
  • ne appartient pas à une instance de classe, ne appartient pas à un objet
  • la syntaxe est class.method.
  • si nous utilisons dans la classe à laquelle le code de classe peut être omis.

On notera également, ECLIPSE aide le développeur afficher le texte d'un procédé statique en italique.

Pour mieux voir cette souris sur l'un des états-dire et de voir ce ECLIPSE savoir la qualification de la méthode. (Voir la capture ci-dessous.)

Le assertEquals méthode statique

JUnit test

Le BillingAddressTest peut maintenant courir pour billingAddress fabricant. Le cliché suivant montre le résultat. Le test a été passé. Le cas de deux de test restant pour setCity et setState être complété suivant.

Le test les résultats jusqu'à présent

Tests d'achèvement

Nous complétons les cas de test à chaque setCity et setState d'une manière similaire. En tout cas, nous créons un objet, puis appelons les assertEquals méthode billingAddress avec la valeur de chaque a été fixé avec l'attendu et invoquons la méthode get pour récupérer le actual.value appropriée.

Le code pour les tests restants

relancez les tests

Maintenant, exécutez à nouveau le test et le succès! Notez la barre verte remplace la couleur de l'écorce de la barre qui se affiche quand il y avait des erreurs.

Le succès de l'affichage des résultats des tests

Vous recherchez un échec de l'essai

Supposons quelque chose ne allait pas avec un test, les informations que nous pourrions arriver à nous aider à résoudre le problème?

Nous créons une erreur dans le deuxième test. Faire une faute de frappe de la valeur attendue pour "Scranton" épeler "Scrantno" et de voir ce qui se passe.

Du point de vue des résultats des tests, sélectionnez le second test, celui qui a échoué et de maximiser l'échec de la piste de partie des résultats des tests vue JUnit. Le texte montre ce qui est faux. Il ya deux icônes en haut à droite de cette partie de la vue montrant d'autres façons de regarder l'erreur. Ces deux modes sont illustrées ci-dessous dans les instantanés.

Deux façons de voir le Trace défaut

Récapitulation et What Next

Dans ce tutoriel, nous avons terminé le terrain d'essai pour les méthodes que nous avons choisi lorsque nous avons créé le programme de test "stub" dans le tutoriel précédent. La méthode échoue (qui est aussi une méthode statique de JUnit logiciel est remplacé par des méthodes appropriées et se définir comme un cas d'essai peut exiger. Nous avons effectué des tests et constaté le succès de l'essai, une fois a été ajouté code approprié. Nous avons aussi regardé deux façons de regarder la sortie d'un échec dans un test.

Dans le tutoriel, nous venons de terminer, les méthodes à tester a été déjà construit. Dans le prochain tutoriel, nous allons voir le cas pour spécifier le test, puis créer la méthode qui va produire la sortie désirée. Ce sera notre premier regard sur la méthode "premier test" et de notre introduction à Testez Driven Development (TDD).

Ce tutoriel peut-être répondre à vos besoins et attentes?

Évaluez-moi! 1 2 3 4 5 Votre vote pour Tutorial IDE Eclipse

Google Android Tablet

HP Pavilion All-In-One

(0)
(0)

Commentaires - 0

Sans commentaires

Ajouter un commentaire

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Caractères restants: 3000
captcha