Discussion :

[francis60]

Bonjour,


Avez-vous testé Rubberduck ( disponible sur ce site: http://rubberduckvba.com/ ) ?

L'add-in COM en anglais permet d'enrichir Visual Basic Editor - qui n'a pas évolué depuis de nombreuses années - avec fonctionnalités de test unitaires, de refactoring et l'inspection du code VBA.

L'IDE Rubberduck promet de nous faire entrer dans le 21ème siècle...

Je recherche des arguments pour convaincre l'IT central d'autoriser l'installation sur mon poste.

Merci pour votre aide

Francis

[Marc-L]

Bonjour,

pas testé et rien de ce qui est proposé ne m'apporterait quelque chose de vraiment utile …
Et je ne prendrais pas le risque de l'installer dans pouvoir vérifier son code source !


______________________________________________________________________________________________________
Je suis Paris, Charlie, Bruxelles, …

[francis60]

Bonjour Marc,

Merci pour ton éclairage.

C'est un projet open source, le code est accessible. Mais qui irait passer des heures à vérifier ?

J'ai trouvé dans la doc en ligne:

• Une fonctionnalité de renommage qui n'est pas juste un replace.
• Un audit qui detecte les variables ou class non utilisées.
• Extraction de fonction...

C'est pas moi qui t'ai moinssoyé

[el_slapper]

Je ne fais pas de VBA assez gros pour que ça vaille la peine, en ce moment(rien qui ne dépasse une demi-heure). Mais par le passé, j'aurais bien aimé avoir ça sous la main.

[Marc-L]

C'est pas moi qui t'ai moinssoyé

Je m'en doute, t'inquiètes …

Encore un imbécile se croyant au dessus du lot, p't'être même qui travaille chez Renault ‼

[loufab]

J'avais pensé à PSA...

Cela parait intéressant sur le papier.
Pour de moyens et gros projets ça peut le faire.

Merci pour cette info en tout cas !

[francis60]

Aujourd'hui mon projet VBA comprend 21 000* lignes de code, je pense que j'aurai l'utilité d'un tel outil.


Comment pourrais-je rassurer l'IT sur les risques à installer cet add-in ?
Le fait qu'il soit open source ne garantit-il pas qu'il ne contienne pas de code malveillant ?
Les buggs évoqués sur le site ne sont liés qu'aux fonctionnalités ajoutées par l'add-in.
Pourrait-il subsister des buggs dangereux ?

*: même pour savoir ça, j'ai dû écrire une macro car VBE ne founit pas la lecture directe du nombre de lignes totales.

[RubberduckVBA]

Tout d'abord, je tiens à remercier tous ceux d'entre vous qui avez téléchargé et essayé cet outil sur lequel je travaille avec acharnement. Je suis le principal développeur et architecte de Rubberduck, et j'avoue être sans mots face à tous les commentaires que je vois en ligne concernant mon bébé.

La dernière version "stable" parue début juillet 2015, v1.4.3, est complètement traduite en Français, ma langue maternelle (aussi traduit en Allemand, en Suédois et en Japonais) - il suffit d'accéder aux options et de choisir Français comme langue d'affichage.

Le projet est effectivement open-source, et je n'ai rien à cacher; si vous téléchargez l'exécutable d'installation directement sur GitHub, il n'y a rien à craindre en ce qui concerne les "malwares" - par contre j'ignore si d'autres sites offrent de télécharger mon exécutable, et si c'est le cas je ne peux pas garantir que le contenu soit celui que j'ai publié sur GitHub.

La force de Rubberduck repose sur sa capacité à analyser le code VBA dans l'éditeur. La version 1.4.3 gère très bien des projets de petite à moyenne taille, mais accrochera sur certaines syntaxes à cause de plusieurs bogues (maintenant résolus) dans la grammaire ANTLR utilisée pour générer le parser (analyseur? lecteur? ...bref le code C# qui a pour responsabilité de "comprendre" le code VBA) - par exemple les lignes numérotées, les deux-points (séparateur d'instructions), ainsi que les appels de propriété indexée sur la valeur de retour d'une fonction (ouf... voir exemple plus bas), feront sauter le "parser", ce qui rend pratiquement inutile la plupart des fonctionnalités.

Par exemple, foo = Range("A1:B12")(i) ne fonctionnera pas, à cause de l'appel indexé (i) qui suit l'appel de la fonction Range. Bien sûr ces bogues peuvent être évités, par exemple en extrayant le résultat de Range("A1:B12") dans une variable locale, puis en accédant à l'index i de cette variable dans une autre instruction. Ou encore en évitant les deux-points et les numéros de lignes.

Les fonctionnalités de refactoring (c'est quoi le mot Français pour ça?!) et les inspections du code dépendent grandement de la capacité de Rubberduck à correctement comprendre le code VBA dans l'éditeur: si une erreur d'analyse survient, il est possible que l'extraction d'une méthode ou le fait de renommer une variable, ne donne pas les résultats escomptés; aussi certaines inspections renverront de faux positifs.

C'est donc à la fois la force et la faiblesse de Rubberduck, du moins en ce qui concerne la version 1.4.3: la version 2.0 (présentement instable, publiée en version alpha seulement) corrige une quantité phénoménale de bogues, et gère parfaitement du code VBA qui faisait sauter l'analyseur de 1.4.3, en plus d'être plus rapide et de travailler en arrière-plan.

Pour peu que Rubberduck parvienne à comprendre le code du projet VBA, les outils de navigation fonctionnent merveilleusement bien; pouvoir visualiser le contenu d'un projet dans une arborescence comme dans Visual Studio permet de rapidement trouver où se trouve le code dans un classeur Excel qui comporte de nombreuses feuilles et quelques modules, sans avoir à chercher partout.

La fonction de tests unitaires requiert l'écriture de code VBA découplé et plus orienté objet que ce qu'on a l'habitude de voir en VBA, mais sortir le code des event handlers pour l'implémenter dans des classes et des fonctions plus spécialisées est une très bonne chose en général. Rubberduck s'en sort très bien en ce qui concerne les tests unitaires, qui sont somme toute assez simples à écrire et basés sur MS-Test. Donc si vous avez déjà écrit des tests dans Visual Studio vous devriez vous retrouver avec la façon dont Rubberduck fonctionne à ce chapitre.

Un point sur lequel 1.4.3 se plante carrément: l'intégration Git / contrôle des sources. Le panneau est là, mais rien ne se passe, rien ne fonctionne. Heureusement, la version 2.0 se ratrappe allègrement et permet de travailler avec un repository sur GitHub (ou BitBucket), complètement VBA et sans jamais quitter l'éditeur - exactement comme le Team Explorer dans Visual Studio.

Bref, Rubberduck est d'abord et avant tout un projet sur lequel je planche justement parce que l'éditeur VBA est pathétique en 2016... et je trouve fascinant le fait d'écrire du code qui traite le code de son utilisateur comme une donnée avec laquelle travailler. De deux développeurs à la fin de 2014, nous sommes maintenant une poignée de développeurs à travailler jour et nuit (du Canada à l'Australie) sur Rubberduck, afin de réussir à publier une version qui fonctionne exactement comme nous l'envisageons... la version 2.0 (bientôt!) corrige tellement de problèmes et est tellement plus agréable que 1.4.3, que j'ai de la difficulté à recommander 1.4.3... 2.0 sera stable sous peu.

Je vous invite à suivre @rubberduckvba sur Twitter et à utiliser le lien "contact us" sur le site du projet si vous désirez plus d'informations. Rubberduck n'est pas un produit commercial; c'est un projet de méta-programmation qui veut donner aux codeurs VBA les outils pour travailler comme les autres développeurs qui travaillent avec d'autres éditeurs dans d'autres languages.

Pourrait-il subsister des buggs dangereux ?

La version 1.4.3 n'a rien de "dangereux" (je sais ...."dit le gars qui a écrit et publié le logiciel"). Le pire qui peut arriver, c'est qu'Excel plante...

Le version 2.0-alpha n'est pas stable, mais n'a rien de "dangereux" non plus; la seule raison pour laquelle cette version a été publiée, c'est parce que ça faisait une éternité qu'on n'avait rien publié et que 2.0 est tellement mieux en tout point que 1.4.3, nous voulions donner quelque chose à mettre sous la dent de ceux qui attendent 2.0 avec impatience.

2.0-beta (stable) devrait être publié d'ici une ou deux semaines, et la version 2.0 finale devrait voir le jour dans les deux semaines suivantes.

Comment pourrais-je rassurer l'IT sur les risques à installer cet add-in ?

Si ça ne presse pas, je suggèrerais d'attendre au moins 2.0-beta. L'add-in requiert les privilèges administrateurs pour l'installation, parce que l'installateur doit enregistrer la librairie Rubberduck.tlb, qui expose un API à VBA et qui sert, entre autres, à faire fonctionner les tests unitaires. D'autres add-ins (MZ-Tools par exemple) ne requièrent pas ces privilèges à l'installation, mais n'enregistrent pas de librairie et n'offrent pas non plus un framework permettant d'écrire et d'exécuter des tests pour votre code VBA.

La macro que vous avez écrite pour compter les 21,000 lignes de code dans votre projet, est plus dangereuse que Rubberduck: vous avez dû autoriser explicitement l'accès au modèle d'objet de l'API VBE, ce qui permet d'exécuter du code qui génère et exécute du code arbitraire - et ÇA c'est un risque réel. Avec Rubberduck, vous pouvez désactiver cette autorisation, parce qu'étant un complément de l'éditeur, Rubberduck dispose déjà de cet accès au code dans l'éditeur: vous n'avez donc pas besoin d'autoriser tout et n'importe quoi à accéder à cet API sensible.

Rubberduck utilise la librairie d'extension que Microsoft a distribué extactement pour la raison pour laquelle Rubberduck l'utilise: ajouter des fonctionnalités à l'éditeur VBA. Cette librairie permet d'accéder aux projets VBA chargés dans l'éditeur, ainsi qu'aux fenêtres, menus et commandes de l'éditeur. Rubberduck se sert de cet API pour exporter/importer les modules dans des fichiers temporaires (pour lire les attributs des modules et procédures, inaccessibles par l'éditeur), pour accéder aux modules et au code tel qu'il apparaît dans l'éditeur, pour ajouter des fenêtres, des commandes, et des menus; bref, Rubberduck a besoin de cet API pour être utile.

Rubberduck 2.0 se sert également de hooks sur le clavier et la souris, afin d'activer et de désactiver des combinaisons de touches ("hotkeys") et de connaître l'emplacement du curseur dans l'éditeur au moment où la sélection change: Rubberduck se sert de cette information pour déterminer quelles commandes contextuelles peuvent être exécutées, juste avant que le menu soit dessiné.

Rubberduck est une extension de l'éditeur VBA, qui est un produit distinct de Microsoft Office: une fois installé sur un poste, Rubberduck se chargera dans toutes les applications hôtes sur ce poste, incluant toutes les applications Office, mais aussi AutoCAD, Sage300, Corel DRAW, Microsoft Project, et toute autre application qui offre un hôte VBA. Le complément peut être désactivé en modifiant la valeur "LoadBehavior" dans la clé de registre qui l'enregistre comme un add-in, ou encore dans le menu "Compléments" de l'éditeur.

La fonctionnalité "contrôle des sources" de la version 2.0, utilise la libraire libgit2sharp (comme Visual Studio!), et les versions futures auront sans doute d'autres dépendances permettant l'intégration de SVN et d'autres systèmes de controle des sources.

Les tests unitaires ne fonctionnent seulement que pour les hôtes dont l'objet Application expose une méthode Run; Microsoft Outlook n'est donc pas supporté. Rubberduck n'exécute que des procédures publiques et sans paramètres, dans un module spécialement identifié comme étant un module de tests, et seulement quand l'utilisateur le demande.

[loufab]

Bonjour,

Tout d'abord merci pour ce complément !
Tellement de chose manque dans VBE.

La force de Rubberduck repose sur sa capacité à analyser le code VBA dans l'éditeur. La version 1.4.3 gère très bien des projets de petite à moyenne taille, mais accrochera sur certaines syntaxes à cause de plusieurs bogues (maintenant résolus) dans la grammaire ANTLR utilisée pour générer le parser (analyseur? lecteur? ...bref le code C# qui a pour responsabilité de "comprendre" le code VBA) - par exemple les lignes numérotées, les deux-points (séparateur d'instructions), ainsi que les appels de propriété indexée sur la valeur de retour d'une fonction (ouf... voir exemple plus bas), feront sauter le "parser", ce qui rend pratiquement inutile la plupart des fonctionnalités.

A ce que j'ai cru comprendre sur Github c'est que le problème de la ligne numérotée serait résolu en 2.1. Peut-on se procurer cette version ([EDIT] en béta)? Tout mes projets utilisent la numérotation (non pas pour faire de vilain goto ) et je n'ai pu le tester/utiliser.

Les fonctionnalités de refactoring (c'est quoi le mot Français pour ça?!)

Oui... refactoring

Donc bravo et merci !

[RubberduckVBA]

A ce que j'ai cru comprendre sur Github c'est que le problème de la ligne numérotée serait résolu en 2.1.

Le problème est contourné avec 2.0; avant de passer le contenu d'un module dans le Parser, on remplace les numéros de lignes par des espaces (seulement en mémoire, pas dans l'éditeur), ainsi les emplacements des tokens sont corrects. J'ai abandonné l'idée de modifier la grammaire pour lui faire comprendre les lines numérotées. C'est sans doute possible, mais le hack fonctionne, alors je suis passé à un autre appel comme on dit.

[francis60]

Bonjour RubberduckVBA,

Merci beaucoup pour ton retour très détaillé.

La macro que vous avez écrite pour compter les 21,000 lignes de code dans votre projet, est plus dangereuse que Rubberduck: vous avez dû autoriser explicitement l'accès au modèle d'objet de l'API VBE, ce qui permet d'exécuter du code qui génère et exécute du code arbitraire - et ÇA c'est un risque réel.

Effectivement, je suis obligé d'autoriser cet accès. J’essaierai de penser à décocher "Trust access to the VBA project model" dans Developer Macro Settings.

J'ai installé RubberDuck sur ma machine perso (car je n'ai pas les droits d'admin pour l'utiliser dans mon travail) et j'ai rencontré les problèmes d'interprétation du code dont tu parles (notamment les retours à la ligne), j'ai commencé à réécrire mon code avec des contournements, mais j'ai abandonné car c'était trop laborieux.
J’attends avec impatience le prochain release stable.

La fonction de tests unitaires m’intéresse beaucoup.
Je me demande si l’outil est capable d’enregistrer au fils de l’eau les saisies, les clics de souris par exemple dans la barre de menu du ruban ou dans un userform et autres actions utilisateur pour reproduire une séquence d’utilisation du programme automatiquement et de tester ensuite une série de résultats attendus ? Je le méprends peut-être sur ce qu’on entend par tests unitaires, car il semble que Rubberduck propose un périmètre de test procédure par procédure en deçà du contexte réel de l’utilisateur final.

Me conseillerais-tu d’essayer la fonction de tests unitaire, sans attendre la nouvelle version?

[loufab]

Bonjour,

Pour moiDans mon cas la V2.0 téléchargée n'est pas fonctionnelle, le menu d'analyse du code est grisé et l'un des items apparait vide.

J'attendrais une version plus stable pour y revenir.
Pour les tests de type IHM (GUI) voir Sikuli.

[RubberduckVBA]

2.0 amène aux tests unitaires quelques options offrant davantage de contrôle quant au contenu d'un nouveau module de tests, et une nouvelle implémentation de IAssert, "PermissiveAssertClass", qui est plus permissive que "AssertClass" au niveau du "type safety". Oh, et une nouvelle interface visuelle et différents formats d'exportation des résultats au presse-papier Windows ("clipboard") - mais la fonctionnalité en tant que tel est la même qu'avec 1.4.3, et les tests écrits avec 1.4.3 s'exécutent avec 2.0 pour peu qu'ils soient décorés de l'annotation "@TestMethod".

Les tests unitaires n'automatisent pas de clics et n'interagissent pas avec une interface utilisateur; ils permettent de tester les méthodes publiques d'objets (et fonctions de modules), et de s'assurer que le code produit les résultats escomptés. Ils sont utiles quand la logique applicative est découplée de la logique de présentation et que les dépendances (feuilles Excel, formulaires, bases de données, fichiers externes, autres objets, etc.) sont contrôlables par les tests, ce qui exige l'écriture de code plus spécialisé, des fonctions qui font une chose et le font bien, des objets aux responsabilités claires - bref du code "testable", dans le sens unitaire du terme.

Un test unitaire qui affiche un formulaire ou un MsgBox, ne remplit pas son rôle: ces tests devraient tester la logique, et cette logique devrait s'exécuter rapidement et surtout sans interaction avec l'utilisateur; il appartient au programmeur d'écrire du code testable, d'extraire la logique applicative de la logique de présentation - et c'est là que les outils de refactoring entrent en scène.

J'espère être en mesure de publier une version 2.0 beta stable d'ici la semaine prochaine :-)