Question 1.

Vous modifiez une fonctionnalité existante et lorsque vous exécutez les tests unitaires,
vous réalisez que 3 tests sont maintenant en échec. Qu’allez-vous faire ?

Question 2. Décrivez 2 propriétés d’un bon test unitaire et indiquez pourquoi ces propriétés doivent
être respectées par les tests unitaires d’un projet.

Isolation : un bon test unitaire doit être isolé, i.e qu’il doit tester une unité de code spécifique
sans dépendre d’autres modules.

Validité : un bon test unitaire doit être valide, i.e qu’il doit tester une fonctionnalité ou un
comportement précis et pertinent de l’unité de code.

Question 3. Votre employeur vient de lire un article sur l'importance des tests unitaires. Il vient donc
de renvoyer tout le département de qualité logicielle en disant qu'il est possible de tester tout le
logiciel avec les tests unitaires. Votre employeur dit qu'il suffit que chaque ligne de code soit associée
à un test unitaire pour s'assurer que tout le logiciel fonctionne. Que lui répondez-vous ?

Question 4. Vous avez une méthode de plus de 200 lignes de code à modifier et il n'existe aucune
couverture de test sur cette méthode. Expliquez la démarche que vous utiliserez pour y faire du
refactoring de façon sécuritaire.

Analyse de la méthode : prendre le temps de comprendre exactement ce que fait la méthode,

comprendre sa fonctionnalité

Création de tests unitaires : créer des tests unitaires pour la méthode.

Refactoring : avec les tests unitaires en place, on peut commencer le refactoring. Simplifier la
méthode, supprimer les duplications de code, extraire les fonctions et les classes…

Vérification de la couverture de test : vérifier que toutes les parties de la méthode sont
couvertes par les tests unitaires.

Test d’intégration : vérifier si la contrainte de non modification du logiciel a été respectés.

Question 5.Quelle est la plus grande crainte des développeurs face au refactoring ?

La plus grande crainte lors du refactoring est de casser le code existant, i.e perturber le
fonctionnement actuel de l’application ou de générer des bugs.

Question 6. Le refactoring et les tests unitaires sont deux pratiques intrinsèquement liées. Pourquoi ?

Le refactoring et les tests unitaires sont deux pratiques intrinsèquement liées car les tests
unitaires permettent de garantir les modifications apportées lors du refactoring n’ont pas altéré le
comportement de l’application.
Question 8. Un logiciel de gestion de sources comme Git est primordial lorsqu’on fait du
développement, pourquoi ?

 Conserver un historique des modifications

 Permettre de travailler à plusieurs
 Permettre les modifications en parallèle
 Garantir la sécurité

Question 9. Quelle est l’utilité de la commande git pull ?

Récupérer les dernières modifications du repository, synchronisation entre les différents

développeurs travaillant sur le même projet.

Question 10. Différence entre intégration continue et intégration classique ?

 Intégration continue : on code, on commite, on teste, …

 Intégration classique : on code tout, puis on teste tout

Question 12. Quelles sont les avantages d’un IDE ?

Productivité : offre divers fonctionnalités, complétion du code, coloration syntaxique,

refactoring, …

Debugging : offre des outils de débogage avancés qui permettent de trouver rapidement les
erreurs de code.

Intégration de l’environnement : outils de builds, outils des tests.

Question 13. Est-ce que chaque membre d'une équipe de développeurs devrait pouvoir choisir son
IDE pour travailler ou le même IDE devrait être utilisé par tous les membres de l’équipe ? Pourquoi ?

Il est recommandé d’utiliser les mêmes de développement pour garantir une certaine
uniformité. Si chaque membre de l’équipe utilise un IDE différent, cela peut entraîner des problèmes
des compatibilités et des difficultés à collaborer efficacement.

Différence entre Git et Github :

Github est un système de gestion de versions, tandis que Github est une plateforme en ligne
construite autour de Git qui permet la collaboration et le partage de code entre les développeurs.

Gestionnaire de sources : outil collaboratif, pourquoi ?

Un gestionnaire de sources est considéré comme un outil collaboratif car :

 Partage de modifications :
 Gestion de conflits : fusion des modifications après résolution des conflits
 Historique de modification : facilite la gestion du version du code et permet aux développeurs
de retrouver la version précédente.
 Facilité de collaboration : outil de communication et de notification pour informer les autres
membres de l’équipe du changement de code.