Présentation de l'interface de consignation des résultats

Si votre code personnalisé utilise l'interface IKLog pour communiquer les résultats des tests, vous pouvez contrôler ces résultats dans l'historique d'exécution du test. Si vous consignez des verdicts de point de vérification personnalisé, ces derniers sont reflétés dans le verdict global des plannings.

Voici quelques exemples de ce que vous pouvez faire avec un code personnalisé :

Dans votre code personnalisé, utilisez l'interface IKLog pour communiquer les résultats de vos tests. Cette interface fait partie du package com.ibm.rational.test.lt.logging. Il existe deux types de méthodes IKLog :

Lorsque vous ajoutez un code personnalisé à un test, les éléments suivants apparaissent dans l'éditeur de test :
détails des éléments de test avec le nom de la classe et les boutons Afficher le code et Générer le code

Si vous cliquez sur Générer le code, un modèle de classe de code personnalisé est créé dans le dossier src du projet. Avant de générer le modèle de classe, vous pouvez entrer un nom de package différent (recommandé, pour éviter que votre code personnalisé ne se trouve dans le même package, test, que le code du test généré) et un nom de classe descriptif de la fonction effectuée par votre code. Vous pouvez également réutiliser un code personnalisé existant en entrant le nom de son package et de sa classe, puis ouvrir la classe en cliquant sur Afficher le code. Par exemple, si vous entrez test.custom.VerifyCustID comme nom de package et de classe, le code illustré ci-après est généré dans src/test/custom/VerifyCustID.java et d'ouvre dans l'éditeur Java.

package test.custom;

import com.ibm.rational.test.lt.kernel.logging.IKLog;

/**
 * @author unknown
 */
public class VerifyCustID implements
		com.ibm.rational.test.lt.kernel.custom.ICustomCode {

	/**
	 * Instances of this will be created using the no-arg constructor.
	 */
	public VerifyCustID() {
	}

	/**
	 * @see com.ibm.rational.test.lt.kernel.custom.ICustomCode#exec(IKLog, java.lang.String[])
	 */
	public String exec(IKLog log, String[] args) {
		return null;
	}

}

Par défaut, la vue Navigateur de test s'ouvre dans la perspective Test. Il s'agit normalement de la meilleure vue pour naviguer dans les tests car elle élimine de nombreux fichiers inutilisés par les testeurs et notamment le contenu du dossier src. Lorsque vous écrivez un code personnalisé, vous pouvez souhaiter ouvrir le navigateur standard ou une vue de navigation Java afin de naviguer directement dans votre code. (Vous pouvez ouvrir le code personnalisé à partir du test appelant en le sélectionnant, puis en cliquant sur le bouton Vue.)

Votre logique personnalisée et vos instructions de consignation sont placées dans le bloc exec dans la partie inférieure. Si vous entrez log. à l'intérieur de ce bloc et que vous cliquez sur Ctrl-espace, l'éditeur Java répertorie les méthodes IKLog et affiche leur documentation Java. Pour manipuler les valeurs d'entrée du test appelant, faites-le sur la matrice args, qui contient les arguments que vous avez désignés lorsque vous avez ajouté le code au test : voir Ajout d'un code personnalisé, étapes 4 à 6. L'instruction return renvoie éventuellement une valeur au test appelant.

Comme illustré dans la rubrique Consignation d'un message simple, vous pouvez écrire un message dans l'historique d'exécution, directement avec reportMessage. Les autres méthodes requièrent l'accès aux classes qui créent des objets événement. Pour accéder à ces classes, ajoutez une ou plusieurs de ces instructions d'importation :

import org.eclipse.hyades.test.common.event.ExecutionEvent
import org.eclipse.hyades.test.common.event.MessageEvent
import org.eclipse.hyades.test.common.event.VerdictEvent

Si vous ajoutez un code personnalisé contenant les instructions d'importation ci-avant à un test d'un projet dans lequel aucun test n'a jamais été exécuté, des erreurs d'importation peuvent survenir. Toutefois, si au moins un test du projet a déjà été exécuté, aucune erreur ne sera générée. En effet, l'exécution d'un test ajoute les bibliothèques connues requises pour l'exécution, y compris les classes nommées dans les instructions d'importation, au chemin de compilation du projet.

La classe VerdictEvent est la plus appropriée pour votre code personnalisé car les verdicts consignés dans l'historique d'exécution avec la méthode reportVerificationPoint sont reflétés dans le verdict de réussite/d'échec du test. Le verdict d'un planning n'est "pass" (réussite) que si tous ses tests aboutissent ou si aucun verdict n'est renvoyé par un test. L'exemple Consignation d'un événement de verdict illustre la manière de créer et de consigner un événement de verdict.

L'éditeur de planning permet de définir le niveau de consignation de l'historique d'exécution. Le tableau ci-après répertorie les paramètres de l'éditeur et le littéral IKLog équivalent.
Tableau 1.
Paramètre de l'éditeur de planning Littéral IKLog
Tous HISTORY_ALL
Néant HISTORY_NONE
Planning HISTORY_SCHEDULE
Page HISTORY_PAGES
Demande HISTORY_REQUESTS

En fonction des paramètres de l'éditeur de planning, les résultats sont retirés de l'historique d'exécution. Il est donc possible qu'un résultat consigné par votre code personnalisé n'apparaisse pas dans l'historique d'exécution. Utilisez getHistoryLevel pour obtenir le paramètre du niveau de l'historique et wouldReportHistory pour renvoyer sous certaines conditions un résultat basé sur ce paramètre. (Si vous exécutez un test directement, le paramètre est HISTORY_ALL.)

Conditions d'utilisation | Commentaires
(C) Copyright IBM Corporation 2005. All Rights Reserved.