Une fois que nous avons des environnements installés il faut les tester et les valider, à la fois dans la ligne de commande (CLI) et dans la console (panneau output) de l’IDE. Soit d’une manière très simple avec un programme de test dans l’environnement (base), soit avec une batterie de tests pour les modules importants qui sont installés, dans (base) et (prod).

Article mis à jour en Janvier 2025.

1. Mini test ultra basique

Si  à ce niveau il y a un problème, il faudra le résoudre car il se propagera dans la suite de l’installation, Windows ou Linux (Ubuntu)  c’est la même approche. Pour un premier test rapide après l’installation, j’utilise souvent un petit programme de calcul de coûts qui a tendance à ressortir quand le prix du carburant augmente.

En mode CLI (cmd)
Si nous avons le programme Python calcul_couts.py dans c:\Dev et en le faisant exécuter (commande python calcul_couts.py) dans (base) :

(base) C:\Dev>python calcul_couts.py Cout journalier Prix Bus Car Gain x4 ============================== gazoil (1 trajet bus) 0.50 gazoil (1 trajet car) 3.37 1.60 5.00 10.75 5.75 22.98 … gazoil (1 trajet bus) 0.75 gazoil (1 trajet car) 5.06 2.40 5.50 14.12 8.62 34.47 ============================== *** Test done.

Avec SciTE (wrap  mode + dark output)

C’est la configuration que j’utilise au quotidien, panneau output en mode sombre (noir ou pas tout à fait car il y a des affichages de résultats que SciTE interprète parfois en noir) :

La recherche des erreurs est fonctionnelle, le click sur une erreur dans le panneau output renvoie sur la ligne correspondante du code et un marquage dans la colonne des numéros, c’est le minimum attendu pour un éditeur de programmation:

A noter, que je n’y suis (presque) pour rien dans les caractères roses dans le panneau output. Suivant les première lettres de la ligne affichée dans la console, celle ci peut prendre différentes couleurs, par exemple si on fait un print("> quelque chose") la ligne s’affichera avec la couleur Teal. Ce qui permet d’augmenter la visibilité des résultats, mais qui ne marche qu’avec SciTE et dans la console SciTE.

2. Mini test avec curses

Curses ou ncurses sont des bibliothèques qui datent des années 90s, et permettaient de gérer des affichages directs à tous les endroits de l’écran. Dans ce cas on utilise le programme Python calcul_couts_curses.py :

Dans une implémentation de curses, on initialise, imprime (ajout de chaînes de caractères)  et synchronise tout ce qui doit être affiché (dans stdscr) puis on envoie au wrapper pour afficher d’un seul coup l’ensemble. Ce n’est pas compliqué et cela permet d’avoir des fonctions avancées (couleurs, fonds, séparateurs …) sans trop de temps d’apprentissage.

En mode CLI + curses

Ce qui nous donnera un affichage plus riche (taper Return pour sortir):

Les bibliothèques curses/ncurses, dont nous avons l’habitude sous Linux/Unix ne sont pas disponibles sous Windows/Python3, il faudra utiliser une librairie compatible.

Pour installer la bibliothèque curses, avec une implémentation qui marche, il est possible d’installer le paquetage conda labscript-suite::windows-curses (2.3.1 win-64).

Avec SciTE (curses)
Le mode curses n’est pas supporté dans le panneau Output. Message d’erreur « redirection not supported ».

SciTE et (Geany sur Windows) n’ont pas une option du type ‘Emulate terminal in output console’ qui permettrait de le faire.

3. Tests étendus

Fini de jouer, on passe à de l’extensif pour valider l’installation. En principe dans c:\Dev\tests-buildez j’utilise une série de répertoires avec un ou plusieurs programmes pour tester le paquetage correspondant, dans les fonctions qui m’intéressent et qui sont différents du code que l’on peut trouver dans les interfaces de test (éventuellement présentes dans les différents modules). Par exemple:

(prod) C:\Dev\tests-buildez>ls -C __init__.py        test_graphviz     test_oasa3        test_rdkit test_basemap       test_inchi        test_openbabel    test_scikit test_biopandas     test_matplotlib   test_pycairo      test_seaborn test_console       test_netcdf4      test_pygtk        test_sqlalchemy test_fafdrugs2l    test_oasa         test_pyqt         test_wrappers ...

Il faut aussi disposer de jeux de données spécifiques pour les tests. Par exemple dans test_openbabel il y a une bibliothèque de 71 molécules au format SDF qui est utilisée pour faire des calculs par les  programmes openbabel01.py et pybel01.py. Les deux font la même chose, le calcul de masses moléculaires, mais l’un utilise l’API OpenBabel et l’autre l’API OpenBabel/Pybel qui ont des formats d’objets/méthodes différents. Il s’agit parfois de programmes très simples, par exemple pour openbabel01.py :

Au niveau exécution on doit avoir une liste de molécules avec à gauche l’id (un descripteur pour le nom) de la molécule et à droite une masse moléculaire :

(prod) C:\Dev\tests-buildez\test_openbabel>python openbabel01.py 5275518 mw=500.545720 5275513 mw=405.242580 9082136 mw=324.373700 ... 9012488 mw=288.298540 9073531 mw=320.774080 7676344 mw=330.785440

L’objectif du test n’est pas de savoir si c’est une masse ou une masse exacte (nb: les molécules dans le fichier SDF ne sont pas hydrogénées) mais d’obtenir le même résultat avec l’API openbabel (from openbabel import openbabel as ob) et pybel (from openbabel.pybel import *) plus simple à utiliser (mais … il faut savoir utiliser les deux). En général si les deux programmes passent le test, il y a de bonnes chances que OpenBabel soit utilisable dans un programme Python.

Dans une primo installation (avant d’exporter un environnement et son fichier de spécifications sur une plateforme similaire) c’est le principe de ces tests de validation:  on installe une série de paquetages, s’il n’y a pas de dépendances bloquantes, on vérifie que tout marche. Ce qui nécessite parfois d’ajouter des PATHs, des fichiers de paramétrage, des librairies (ex: DLLs) … Puis quand tout est OK, on documente, puis on passe au groupe de paquetage suivant, en espérant que rien ne va être cassé.