💻 TP − Testabilité et doublures

L’objectif de ce TP est d’appliquer les principes et techniques vues en cours pour analyser et gérer les problèmes de testabilité.

1. Projet à tester

Le projet logiciel considéré est une petite bibliothèque permettant d’implémenter une application de discussion capable de se connecter à un serveur appelé SmallChat. Cette bibliothèque permet donc de se connecter au serveur, d’envoyer des messages, de récupérer des messages, etc.

L’objectif est de réussir à tester la classe SmallChatClientImpl.

Ce projet logiciel est disponible ici : https://gitlab.univ-nantes.fr/naomod/testing/testing-resources/smallchat

2. Exercices

2.1. Analyse de la testabilité

  1. Lisez le code source du projet qui vous est fourni − faites bien attention à regarder à la fois les interfaces et les classes. Faites un diagramme de classe UML simplifié (sans attributs ni opérations) illustrant les relations entre les interfaces et classes du problème.

  2. On souhaite tester par exemple la méthode login de la classe SmallChatClientImpl. Quel problème de testabilité doit être résolu pour cela ? Indiquez les facteurs de testabilité correspondants.

  3. Comment résoudre ce problème de testabilité à l’aide de doublure de test ?

  4. Modifiez le code source du logiciel de manière à permettre l’utilisation d’une doublure de test.

2.2. Écriture des tests

Implémentez les scénarios de test suivants de la classe SmallChatClientImpl.

La spécification de cette classe se trouve dans l’interface SmallChatClient.
Les scénarios sont volontairement écrits de manière pas toujours précise, c’est à vous de notamment bien comprendre quel oracle est nécessaire pour chacun d’entre eux !
Attention à bien également lire la spécification de l’interface SmallChatServerConnection, car vos doublures doivent être cohérents avec cette spécification !

2.2.1. Données de test récurrentes

Pour nos tests, on considère les trois serveurs imaginaires suivants, chacun dans un état spécifique :

  • EmptyServer, qui ne possède rien du tout (ni compte, ni salons).

  • GoodServer, qui possède :

    • un compte dans l’identifiant est chickpea, dont le nickname est ChickPea77, et dont le mot de passe est hummus.

    • deux salons de discussions :

      • general, qui est le salon par défaut, dans lequel on trouve :

        • deux participants existants nommés SoyBean et Lupin,

        • deux messages, un premier envoyé par SoyBean contenant "Bonjour !" et un second envoyé par Lupin contenant "Salut !".

      • food, un autre salon sans information particulière.

  • BadServer, pour lequel la connection ne fonctionne jamais.

2.2.2. Méthode login

Scénario de réussite

Le client peut se connecter au GoodServer avec succès avec le compte chickpea. À la suite de cela :

  • Le client a bien récupéré bien le nickname du compte et le salon par défaut,

  • Le client a bien rejoint le salon par défaut,

  • Le client a bien récupéré les messages et membres du salon par défaut,

  • Le client a bien récupéré la liste des autres salons disponibles.

Scénario d’échec 1 : mauvais compte

Le client ne peut pas se connecter au EmptyServer avec un compte lentil et le mot de passe dhal.

Scénario d’échec 2 : mauvais mot de passe

Le client ne peut pas se connecter au GoodServer avec le compte chickpea et le mot de passe guacamole.

Scénario d’échec 3 : déjà logué

Après s’être déjà logué, le client ne peut pas se *re*connecter au GoodServer avec le compte chickpea.

Scénario d’échec 4 : connection impossible

Le client ne peut pas se connecter au BadServer avec succès avec le compte chickpea.

2.2.3. Méthode changeNickName

Scénario de réussite

Après s’être logué avec le compte chickpea sur le GoodServer, le client peut changer son nickname en Falafel. Suite à cela, le nickname est bien changé côté client, et a bien été changé côté serveur.

Scénario d’échec 1 : non logué

Sans être logué, le client ne peut pas changer son nickname avec le compte chickpea sur le GoodServer.

2.2.4. Méthode changeRoom

Scénario de réussite

Après s’être logué, le client peut rejoindre le salon food avec le compte chickpea sur le GoodServer. Suite à cela, le salon courant est bien changé côté client, et a bien été changé côté serveur.

Scénario d’échec 1 : non logué

Sans être logué, le client ne peut pas rejoindre le salon food avec le compte chickpea sur le GoodServer.

Scénario d’échec 2 : salon invalide

Après s’être logué, le client ne peut pas rejoindre le salon bicycle (car inexistant) avec le compte chickpea sur le GoodServer.

2.2.5. Méthode sendMessage

Scénario de réussite*

Après s’être logué, le client peut envoyer un message "Salutations !" avec le compte chickpea sur le salon general du GoodServer. Suite à cela, après utilisation de refreshMessages ce message est bien présent dans la liste des messages du salon, avec le bon émetteur.

Scénario d’échec : non logué

Sans être déjà logué, le client ne peut pas envoyer un message "Salutations !" avec le compte chickpea sur le salon general du GoodServer.

2.2.6. Méthode logOut

Scénario de réussite*

Après s’être logué, avec le compte chickpea sur le GoodServer, le client peut se déloguer. Suite à cela, il n’est plus possible d’envoyer un message.

Scénario d’échec*

Sans être déjà logué, le client ne peut pas se déloguer.