Bonjour à tou⋅te⋅s

Voici notre liste candidate pour la campagne BdE :

En programmation informatique, le Test unItaIrE (ou « T.U. », ou « U.T. » en anglais) ou test de composants est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module »).

Voici la composition de notre liste :

Bureau

• Président⋅e : Olivier ''Jed'' BÈGUE (2A) – == Origine et histoire ==.
• Vice-Président⋅e : Théo ''Lazza'' LAZZARONI (1A) – A la même époque, ATTOL Unit test est développé, puis utilisé par Sextant Avionique en 1998.
• Trésorier⋅ère : Clément ''The Bot'' PERESSE (2A) – Initialisation (fonction setUp) : définition d'un environnement de test complètement reproductible (une fixture).
• Vice-Trésorier⋅ère : Killian ''Stryt'' DELARUE (2A) – Vérification (utilisation de fonctions assert) : comparaison des résultats obtenus avec un vecteur de résultat défini.
• Secrétaire Général⋅e : Antoine ''Daemon'' PASCALET--GRADOLATTO (1A) – Ces tests définissent le résultat du test : SUCCÈS (SUCCESS) ou ÉCHEC (FAILURE).

Pôle Partenariats

• Loan ''LR'' GODARD (1A) – On peut également définir d'autres résultats comme EVITE (SKIPPED).
• Jérémie ''bleh'' SPIESSER (1A) – Désactivation (fonction tearDown) : désinstallation des fixtures pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants.

Pôle Animations

• Jonathan ''Jirachi'' DEGAND (2A) – Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls).
• Yacine ''DBA3'' ACHEROUFKEBIR (2A) – L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements).

Pôle Communication

• Antoine ''Leffe'' LEEFSMA (2A) – L'emploi d'une « stratégie de test » particulière peut limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de Test unItaIrE à rejouer.
• Terence ''Tété'' NGO (1A) – Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications.

Pôle Événements et Voyages

• Antony Fred ''ElAbuelo'' BACILIO SALAZAR (2A) – Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer.
• Pierre-François ''PAF'' ALIAGA (2A) – Ceci a pour but de définir une fonction qui teste « quelque chose ».

Pôle Logistique

• Respo Foyer : Maël ''Baboul'' BERROU (1A) – Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple.
• Respo Associations : Alexis ''Poseidon'' HOUSSARD (2A) – Ce nouveau test fera faillir le code principal.
• Respo Fipa : Marwan ''Kart'' GUERNOUG (2A) – Modifier le code principal pour faire réussir les tests.

Membres d'Honneur

• Marine ''Rin'' PALLOTTA (3A) – Recommencer, en éliminant et refactorisant les éventuelles redondances dans le code des tests.
• Alexandre ''Baelish'' BRUNOUD (3A) – On refactorise en même temps le code principal que le code des tests.
• Omar ''Omayos'' TALIBI (3A) – Un Test unItaIrE doit tester une caractéristique et une seule.

Bonne campagne ! :)

Test unItaIrE < informatique >