Tests pour la section 4.1.4.1 : Éléments de l'interface graphique des filtres

1) Test pour vérifier que l'interface du tableau de filtres s'affiche

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.4.1 : Éléments de l'interface graphique des filtres.

Fonction 1 : Le tableau de filtres se trouve à droite de l'écran puis offre une liste de filtres disponibles pour le document en question.

Les objectifs principaux du test:

Vérifier que l'interface du tableau de filtres est affichée, qu'on peut voir la liste de filtres et qu'ils sont à la bonne position dans l'écran.

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur vérifie la position du tableau de filtres dans l'interface graphique, elle doit être à droite du document.
4. Puis l'utilisateur vérifie qu'il y a des filtres affichées dans le tableau.

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: N/A
2. Les résultats attendus: la table est affichée à droite de l'écran puis elle contient des filtres.
3. Critère de validation : L'utilisateur peut facilement voir la table et les filtres.

2) Test pour vérifier la correspondance des couleurs des annotations dans le texte et des filtres

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section4.1.4.1 : Éléments de l'interface graphique des filtres

Les objectifs principaux :

Vérifier que les couleurs des annotations dans le texte correspondent aux couleurs de leur type dans le filtre positionné à droite de l'écran.

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. L'utilisateur attend le chargement des filtres et des annotations dans le texte.
3. L'utilisateur sélectionne un segment de texte pas annoté.
4. La fenêtre de gestion d'annotations va s'ouvrir.
5. L'utilisateur ajoute une annotation pour ce segment.
6. L'utilisateur vérifie que la couleur de ce segment de texte annoté ou la couleur de son étiquette correspond à la couleur du filtre
7. L'utilisateur répète les actions 3 à 6 pour les autres filtres disponibles du document.

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
4. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Les couleurs des annotations dans le texte correspondent aux couleurs des filtres correspondants dans la table des filtres située à droite de l'écran.
3. Critère de validation : L'utilisateur peut facilement distinguer entre les couleurs des filtres.

3) Test pour la mise à jour de la table des filtres et la désactivation d'un filtre d'annotation.

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section4.1.4.1 : Éléments de l'interface graphique des filtres.

Fonction 2 : Quand un utilisateur supprime la dernière annotation d'un certain type, le tableau de filtres doit se mettre à jour et décocher le filtre de cette annotation dans le tableau de filtres de ce document.

Les objectifs principaux:

La mise à jour de la table des filtres et la suppression d'un genre d'annotation.

Une description de scénario 1 (défaut)

1. L'utilisateur ouvre la page du document à annoter.
2. L'utilisateur attend le chargement des filtres et des annotations dans le texte.
3. L'utilisateur double-clique une annotation dans le texte.
4. La fenêtre de gestion d'annotations s'ouvre.
5. L'utilisateur supprime l'annotation.
6. L'utilisateur répète les actions 3 à 5 pour tous les annotations d'un type dans le texte, jusqu'à ce que tous les annotations de ce type dans le texte sont enlevées.
7. L'utilisateur vérifie que le filtre de ce type d'annotation est en état inactif ou décochée dans la table des filtres.

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Existence de segments annotés dans le texte.
4. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
5. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Une fois la dernière annotation d'un type est supprimée du texte, le filtre se met à jour et se montre dans un état inactif ou décochée.
3. Critère de validation : L'utilisateur peut facilement distinguer entre un filtre inactif (décoché) et actif (coché)

4) Test lors d'un ajout ou d'une suppression d'une type d'annotation, l'interface graphique du tableau doit se mettre à jour et afficher le nouveau tableau de filtres.

Le type de test:

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges :

Section 4.1.4.1 : Éléments de l'interface graphique des filtres

Fonction 3 : Lors d'un ajout ou d'une suppression d'une type d'annotation (entité ou évènement) par l'administrateur, l'interface graphique du tableau doit se mettre à jour et afficher le nouveau tableau de filtres.

Les objectifs principaux:

Vérifier que lorsque l'administrateur ajoute ou supprime une type d'annotation, l'interface graphique met à jour le tableau de filtres.

Description de scénario 1 (ajouter un filtre) :

1. L'administrateur ouvre la page de gestion des annotations du projet.
2. L'administrateur ajoute une type d'annotation.
3. L'utilisateur ouvre la page du document de ce projet.
4. L'utilisateur attend le chargement des filtres.
5. L'utilisateur vérifie que le nouveau filtre correspondant au nom du type de l'annotation est dans le tableau de filtres à droite du document.

Contraintes liées à ce scénario :

1. Existence d'un document et d'un projet auquel l'utilisateur a accès.
2. Existence d'un tableau de filtres à droite du document.
3. Existence d'un projet auquel le document en question fait partie.
4. Un administrateur doit ajouter une type d'annotation.
5. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Lorsque l'administrateur ajoute une type d'annotation, l'interface graphique du document met à jour le tableau de filtres.
3. Critère de validation : L'utilisateur peut facilement voir que le filtre est ajouté.

Description de scénario 2 (enlever un filtre) :

1. L'administrateur ouvre la page de gestion des annotations du projet.
2. L'administrateur enlève une type d'annotation.
3. L'utilisateur ouvre la page du document de ce projet.
4. L'utilisateur attend le chargement des filtres.
5. L'utilisateur vérifie que le nouveau filtre correspondant au nom du type de l'annotation est dans le tableau de filtres à droite du document.

Contraintes liées à ce scénario :

1. Existence d'un document et d'un projet auquel l'utilisateur a accès.
2. Existence d'un tableau de filtres à droite du document.
3. Existence d'un projet auquel le document en question fait partie.
4. Un administrateur doit ajouter une type d'annotation.
5. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Lorsque l'administrateur enlève une type d'annotation, l'interface graphique du document met à jour le tableau de filtres.
3. Critère de validation : L'utilisateur peut facilement voir que le filtre est enlevé.

Tests pour la section 4.1.4.2 : Éléments logiques des filtres

1) Test pour vérifier que les filtres sont en état actif lors du chargement du document puis la case de ces filtres est cochée indiquant que le filtre est actif.

Le type de test:

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.4.2 : Éléments logiques des filtres

Fonction 1 : Lorsque l'utilisateur charge le document, au début de son travail avec celui-ci, les filtres du document doivent être en état actif si le document possède des annotations de ces filtres. Et la case du filtre est cochée indiquant que le filtre est actif.

Les objectifs principaux:

Vérifier que les filtres sont en état actif lors du chargement du document puis la case de ces filtres est cochée indiquant que le filtre est actif.

Description de scénario (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations dans le texte se chargent.
3. L'utilisateur vérifie que pour chaque type d'annotation dans le texte, le filtre correspondant est actif puis sa case est cochée.

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Existence des annotations dans le texte.
4. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Les filtres sont actifs puis leurs cases sont cochées lorsque l'utilisateur charge le document et qu'il y a des annotations de ces filtres dans le texte.
3. Critère de validation : L'utilisateur peut facilement voir que le filtre est en état actif.

2) Test pour vérifier qu'en décochant une case, les annotations de ce genre deviennent entièrement masquées.

Le type de test:

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.4.1 Éléments de l'interface graphique des filtres.

Fonction 2 : Les filtres vont masquer ou montrer seulement leurs annotations respectives lorsque l'utilisateur va les cocher ou décocher.

Les objectifs principaux:

S'assurer que seulement les filtres actifs vont être affichées dans le texte et non les filtres inactifs.

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations dans le texte se chargent.
3. Repérer une annotation d'un filtre X dans le texte.
4. Faire un clic-gauche sur la case du filtre X dans le tableau des filtres pour le désactiver.
5. Vérifier que le texte ne possède pas d'annotations de ce filtre ou de cette couleur.

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Existence des annotations dans le texte.
4. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
5. Un utilisateur doit avoir le droit d'annoter le texte.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Lorsque l'utilisateur décoche une case d'un filtre dans le tableau des filtres, les annotations de ce type vont se masquer dans le texte.
3. Critère de validation : L'utilisateur peut facilement masquer des annotations.

Tests pour la section 4.1.5 : Fonctions de l'interface graphique pour l'édition des annotations

1) Test pour vérifier que la fenêtre de gestion d'annotations s'affiche et montre les types d'annotations disponibles

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Références au cahier des charges:

Section 4.1.5 : Fonctions de l'interface graphique pour l’édition des annotations

Fonction 1 : La fenêtre de gestion d'annotations s'affiche lorsque l'utilisateur sélectionne un segment de texte. La fenêtre montre les données de collections du document et du projet […]

Section 4.1.2 Modifier une annotation

Les objectifs principaux du test:

Vérifier que l'interface de la fenêtre de gestions d'annotations est affichée, puis qu'on peut voir les types d'annotations constituant les données de collections du document.

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur sélectionne un segment de texte.
4. La fenêtre de gestion d'annotations s'affiche.
5. Puis l'utilisateur vérifie qu'il y a deux listes de types d'annotations dans la fenêtre une pour les entités et l'autre pour les évènements.

Contraintes liées à ce scénario :

1. Existence des types d'annotations disponibles ou des données de collections pour le document en question.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine. Existence d'un document et d'un projet auquel l'utilisateur a accès.
4. L'utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: N/A
2. Les résultats attendus: la fenêtre de gestion d'annotations s'affiche et montre les types d'annotations du document.
3. Critère de validation : L'utilisateur peut facilement voir les types d'annotations dans la fenêtre.

2) Test pour vérifier que l'utilisateur peut ajouter ou supprimer des annotations dans le texte.

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.5 : Fonctions de l'interface graphique pour l’édition des annotations

Fonction 2 : L'utilisateur pourra annoter le texte en sélectionnant un segment du texte. Si le segment de texte n'est pas déjà annoté, l'utilisateur pourra choisir le type d'annotation d'entité puis annoter le segment. Si le segment est déjà annoté l'utilisateur pourra enlever l'annotation ou mettre une annotation d'évènement entre deux entités.

Les objectifs principaux du test:

Vérifier que l'utilisateur peut ajouter ou supprimer des annotations dans le texte.

Description de scénario 1 (Ajout d'une annotation d'entité) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur sélectionne un segment de texte pas annoté.
4. La fenêtre de gestion d'annotations va apparaitre.
5. L'utilisateur choisit le type d'annotation d'entité à mettre.
6. L'utilisateur clique sur le bouton « OK »
7. Le texte va être coloriée dans la couleur du type de cette annotation et le nom du type va apparaître au-dessus du segment annoté.

Contraintes liées à ce scénario:

1. Existence des types d'annotations disponibles ou des données de collections pour le document en question, dans la fenêtre de gestion d'annotations.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
4. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation:

1. Données en entrée: N/A
2. Les résultats attendus: Le segment de texte est annoté avec le type d'annotation d'entité desirée.
3. Critère de validation : L'utilisateur peut facilement annoter le texte avec le type d'annotation d'entité desirée.

Description de scénario 2 (Ajout d'une annotation évènement) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur double-clique sur une annotation de type entité qui ne fait pas partie d'un évènement.
4. La fenêtre de gestion d'annotations va apparaitre.
5. L'utilisateur choisit le type d'annotation d'évènement à mettre.
6. L'utilisateur clique sur le bouton « OK »
7. L'étiquette du type d'annotation d'évènement va apparaitre au-dessus du segment de texte avec le bon nom du type d'annotation.
8. L'utilisateur répète les actions 3 à 7 pour au moins une autre annotation de type entité.

Contraintes liées à ce scénario:

1. Existence des types d'annotations disponibles pour le document en question, dans la fenêtre de gestion d'annotations.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
4. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation:

1. Données en entrée: N/A
2. Les résultats attendus: au moins deux nouvelles annotations d'entités font partie du même évènement.
3. Critère de validation : L'utilisateur peut facilement annoter les annotations entité et créer des évènements.

Description de scénario 3 (Supprimer une annotation) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur double-clique sur l'étiquettes d'une annotation.
4. La fenêtre de gestion d'annotations s'ouvre.
5. L'utilisateur clique sur le bouton « Delete »
6. L'étiquette de l'annotation va disparaitre au-dessus du segment annoté, si c'est une annotation de type entité, le texte va se de-colorier aussi.

Contraintes liées à ce scénario:

1. Existence d'un document et d'un projet auquel l'utilisateur a accès.
2. Existence des types d'annotations ou des données de collections disponibles pour le document en question.
3. Existence de segments annotés dans le texte.
4. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
5. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation:

1. Données en entrée: N/A
2. Les résultats attendus: L'annotation désirée est enlevée.
3. Critère de validation : L'utilisateur peut facilement enlever une annotation dans le texte.

3) Test pour vérifier que l'utilisateur peut créer un lien par flèche entre deux segments annotées du document.

Le type de test :

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.5 : Fonctions de l'interface graphique pour l’édition des annotations

Fonction 6 : L'utilisateur peut faire des liens entre deux segments de texte annotés avec des flèches. En cliquant sur un segment avec la souris puis en déplaçant le curseur vers un autre segment de texte annoté, une flèche va apparaitre. Et lorsque le bout de la flèche va toucher l'étiquette de l'autre annotation, la flèche va se stabiliser et créer une relation entre ces deux segments.

Les objectifs principaux du test:

Vérifier que l'utilisateur peut ajouter un lien par flèche entre deux segments de texte annotés.

Description de scénario 1 (Ajout d'une annotation d'entité) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent.
3. L'utilisateur clique sur un segment de texte avec sa souris
4. L'utilisateur déplace le curseur vers un autre segment de texte annoté.
5. Lorsque le bout de la flèche touche le segment annote, la flèche se stabilise et une relation se crée entre ces deux segments.

Contraintes liées à ce scénario:

1. Existence des annotations dans le document.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
4. Un utilisateur doit avoir le droit d'annoter le document.

Les données en entrée, les résultats attendus et les critères de validation:

1. Données en entrée: N/A
2. Les résultats attendus: Une flèche se forme entre les deux segments de texte désirées.
3. Critère de validation : L'utilisateur peut facilement créer un lien par flèche entre deux segments annotées.

Test pour le code écrit au devoir 3 :

Le filtrage des annotations dans l'interface graphique

Le type de test:

Fonctionnel, on vérifie le fonctionnement d'une composante.

Boîte noire, on ne regarde pas le code

Référence au cahier des charges:

Section 4.1.4.1 Éléments de l'interface graphique des filtres.

Fonction 2 : En décochant une case, les annotations de ce genre deviennent entièrement masquées.

Les objectifs principaux:

S'assurer qu'en cliquant sur un bouton d'un filtre ou mot-clé spécifique on peut voir ou cacher tous les sections annotées par ce mot-clé.

Description de scénario :

Étape	Point de contrôle?	Action	Valeurs à saisir	Valeurs attendues
1	Oui	Effectuer un clic sur un mot-clé activé dans l'interface graphique		Vérification que les segments du texte annotés par ce mot-clé sont cachées
2	Oui	Effectuer un clic sur un mot-clé désactivé dans l'interface graphique		Vérification que les segments du texte annotés par ce mot-clé sont visibles

Contraintes liées à ce scénario :

1. Existence des filtres disponibles pour le document en question, dans le tableau de filtres.
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.
3. Existence des annotations dans le texte.
4. Un utilisateur doit faire les étapes demandées de lui pour effectuer ce test. Intervention humaine.
5. Un utilisateur doit avoir le droit d'annoter le texte.

Les données en entrée, les résultats attendus et les critères de validation.

1. Données en entrée: N/A
2. Les résultats attendus: Lorsque l'utilisateur décoche une case d'un filtre dans le tableau des filtres, les annotations de ce type vont se masquer dans le texte. Et lorsqu'il coche une case, les annotations vont se rendre visibles.
3. Critère de validation : L'utilisateur peut facilement masquer ou rendre visible les annotations.

Test s'assurant que la fonction showFilter() identifie le bon nombre d'éléments

Le type de test :

Unitaire, on vérifie le fonctionnement ds'une fonction du composant filter.

Boîte blanche, on regarde le code

Les objectifs principaux du test:

Vérifier que la fonction showFilter() remplit l'attribut filterElements avec le bon nombre d'éléments

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent, la fonction showFilter est appelée.
3. La fonction remplit l'attribut avec les éléments à filtrer

Contraintes liées à ce scénario :

1. Existence d'au moins un type d'annotation dans le document
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: les éléments filtrable récupérés par le service.
2. Les résultats attendus: le tableau d'élément est rempli d'autant d'éléments que la donnée en entrée
3. Critère de validation : le tableau d'élément est rempli d'autant d'éléments que la donnée en entrée

Test s'assurant que la fonction highlightFilter() change les éléments de filtre de la bonne couleur

Le type de test :

Unitaire, on vérifie le fonctionnement ds'une fonction du composant filter.

Boîte blanche, on regarde le code

Les objectifs principaux du test:

Vérifier que la fonction highlightFilter() modifie les éléments de la liste de filtrage pour que leur couleur de fond correspondent à la couleur de fond des annotations

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. Les filtres et les annotations se chargent, la fonction highlightFilter est appelée.
3. La fonction modifie l'attribut background color des éléments

Contraintes liées à ce scénario :

1. Existence d'au moins un type d'annotation dans le document
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: les highlights récupérés par le service
2. Les résultats attendus: chaque élément est modifié par une couleur identique à celle du highlight
3. Critère de validation : chaque élément est modifié par une couleur identique à celle du highlight

Test s'assurant que la fonction showElements() change bien l'attribut 'Display' de ceux-ci

Le type de test :

Unitaire, on vérifie le fonctionnement ds'une fonction du composant filter.

Boîte blanche, on regarde le code

Les objectifs principaux du test:

Vérifier que la fonction showElements() change l'attribut display des éléments et des highlights à Block pour chaque annotation qui doit être affichée

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. L'utilisateur décoche puis recoche la case d'un filtre
3. La fonction showElements() est appelée
4. La fonction modifie l'attribut display des éléments et des highlights pour les afficher

Contraintes liées à ce scénario :

1. Existence d'au moins un type d'annotation dans le document
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: name = le nom du groupe d'élément à filtrer (le nom de l'annotation)
2. Les résultats attendus: chaque élément est modifié pour pouvoir être affiché
3. Critère de validation : chaque élément est modifié pour pouvoir être affiché

Test s'assurant que la fonction hideElements() change bien l'attribut 'Display' de ceux-ci

Le type de test :

Unitaire, on vérifie le fonctionnement ds'une fonction du composant filter.

Boîte blanche, on regarde le code

Les objectifs principaux du test:

Vérifier que la fonction hideElements() change l'attribut display des éléments et des highlights à None pour chaque annotation qui doit être masquée

Description de scénario 1 (défaut) :

1. L'utilisateur ouvre la page du document à annoter.
2. L'utilisateur décoche la case d'un filtre
3. La fonction hideElements() est appelée
4. La fonction modifie l'attribut display des éléments et des highlights pour les masquer

Contraintes liées à ce scénario :

1. Existence d'au moins un type d'annotation dans le document
2. Existence d'un document et d'un projet auquel l'utilisateur a accès.

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: name = le nom du groupe d'élément à filtrer (le nom de l'annotation)
2. Les résultats attendus: chaque élément est modifié pour pouvoir être masqué
3. Critère de validation : chaque élément est modifié pour pouvoir être masqué

Test s'assurant que la fonction getFiltrableElements() récupère les éléments filtrables

Le type de test :

Unitaire, on vérifie le fonctionnement d'une fonction du service filter.

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère tous les éléments filtrables

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère tous les éléments filtrables
3. Critère de validation : Les éléments filtrables du MOCK ont été identifiés

Test s'assurant que la fonction getFiltrableElements() récupère le même nombre éléments que la fonction getHighlights();

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'éléments récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère le même nombre d'éléments que la fonction getHighlights();

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: Les fonctions récupèrent tous les éléments filtrables et tous les highlights
3. Critère de validation : Les éléments filtrables du MOCK récupéré par getFiltrableElements() et égal à ceux récupérés par getHighlights()

Test s'assurant que la fonction getFiltrableElements() récupère toutes les entités "Symptom"

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'entités "Symptom" récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère toutes les entités "Symptom"

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère toutes les entités "Symptom"
3. Critère de validation : Les entités "Symptom" du MOCK sont toutes identifiées

Test s'assurant que la fonction getFiltrableElements() récupère toutes les entités "a"

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'entités "a" récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère toutes les entités "a"

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère toutes les entités "a"
3. Critère de validation : Les entités "a" du MOCK sont toutes identifiées

Test s'assurant que la fonction getFiltrableElements() récupère toutes les entités "t"

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'entités "t" récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère toutes les entités "t"

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère toutes les entités "t"
3. Critère de validation : Les entités "t" du MOCK sont toutes identifiées

Test s'assurant que la fonction getFiltrableElements() récupère toutes les entités "Medication"

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'entités "Medication" récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère toutes les entités "Medication"

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère toutes les entités "Medication"
3. Critère de validation : Les entités "Medication" du MOCK sont toutes identifiées

Test s'assurant que la fonction getFiltrableElements() récupère toutes les entités "Titre"

Le type de test :

Unitaire, on vérifie l'exactitude du nombre d'entités "Titre" récupéré

Les objectifs principaux du test:

Vérifier que la fonction getFiltrableElements() récupère toutes les entités "Titre"

Les données en entrée, les résultats attendus et les critères de validation :

1. Données en entrée: Une page HTML MOCK qui contient des annotations de brat
2. Les résultats attendus: La fonction récupère toutes les entités "Titre"
3. Critère de validation : Les entités "Titre" du MOCK sont toutes identifiées