Feat/add plugin bc test

[kwizer15]

Ajout de tests de rétrocompatibilité et tests unitaires DB

Description

Cette PR introduit plusieurs améliorations majeures pour les tests :

1. Tests de rétrocompatibilité pour les plugins :

• Implémentation de tests pluginBCTest pour valider la rétrocompatibilité
• Ajout d'un outil generatePhpPublicApi.php pour générer la liste des APIs publiques
• Création d'un fichier de référence api_file listant les APIs à maintenir

2. Tests unitaires pour la classe DB :

• Tests complets des méthodes de la classe DB (select, inserts, updates... )
• Vérification des cas d'erreur et des comportements attendus
• Tests sur les hooks (pre/post save, encrypt/decrypt...)

3. Correction et intégration :

• Correction des tests legacy qui sont maintenant pleinement fonctionnels
• Intégration des tests au workflow CI/CD GitHub

Ces améliorations permettront de :

• S'assurer que les mises à jour du core ne cassent pas la compatibilité avec les plugins existants
• Garantir le bon fonctionnement de la couche d'accès aux données
• Automatiser la validation de la qualité du code via les workflows

Suggested changelog entry

• Added backward compatibility tests for plugins
• Added unit tests for DB class
• Fixed legacy tests
• Integrated tests into CI/CD workflow

Related issues/external references

N/A

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[kwizer15]

Bug to fix here ?

if ($errorInfo[0] !== '00000') {

Quand on envoi un paramètre qui n’existe pas dans la requète, ca ne passe pas dedans.
Le vrai code 00000 (5 zéro) et est une chaine de caractère. Là on pourrait retirer 3 zéros, ca ferai la même chose.

(voir test_query_with_bad_parameter, qui correspond au comportement actuel, devrait probablement renvoyer une exception)

[pifou25]

Ici pour les workflow github on est dans un env de type docker on n'a pas besoin justement de ta PR sur le .env en mode php, il suffit d'utiliser les variables d'environnement pour générer le fichier common.config.php ... Tu pourrais séparer les 2 ?

J'ai tenté il y a qq mois de faire passer les tests phpunit existant mais pas réussi, avec un workflow spécifique (sur mon repo pour l'instant):
https://github.com/pifou25/jeedom-core/blob/feat/run_phpunit/.github/workflows/phpunit.yml

[kwizer15]

Ici on ne génère aucun fichier justement, j'utilise directement les variables d'environnements.
Effectivement on pourrait le faire, on peut tout faire) mais ca rendrait le fichier github plus compliqué, le lancement des tests en local plus compliqué.

Et là tout fonctionne.

[kwizer15]

P'tit up @zoic21 si tu trouves un peu de temps a y consacrer.

[Mips2648]

Et si on veut faire un breaking change, comment on fait alors?
pcq ca peut arriver... c'est juste un changement de version majeure

[kwizer15]

Oui, tu regénères le fichier avec le script qui se trouve dans la pr pour reset.

[kwizer15]

D'ailleurs c'est une bonne question, où est-ce qu'on documente ce genre de chose ?

[Mips2648]

• vu que c'est le workflow qui va casser, je mettrais l'info dans un "echo" du workflow en cas d'échec déjà,
  le log du workflow c'est le premier truc qui j'irais voir.
• un peu de commentaire dans le workflow peut aider
• et un readme dans le dossier xxunit dans lequel se trouve le script en question avec l'explication de comment l'utiliser, p-e que ca y est mais je n'ai pas vu

bref, un truc pour que quelqu'un qui ne sait absolument pas comment ca fonctionne puisse s'y retrouver;
j'ai un peu regarder et c'est pas très intuitif par où commencer; hors si dans x mois t'es plus là, faut que quelqu'un d'autre comprenne ce que tu as fait

[kwizer15]

Bonjour,

Merci pour le retour.

• Je ne comprend pas ta première proposition : en effet, si les tests détectent un BC, les test vont échouer et la tâche en question aussi. Le test qui échoue va s’afficher naturellement à la fin des logs dans le workflow (je peux faire volontairement une modif pour que tu vois le résultat si tu le souhaites). Les "warning" comme dans exemple sont uniquement pour signaler qu’il y a eu des changements non impactant, mais qu’il faudra par la suite regénérer le fichier "témoin" afin de prendre en compte ces modifications pour les tests futurs.
• Je vais rajouter des commentaires dans le workflow et probablement séparer les différentes suites de tests, ca sera plus parlant.
• Je ne sais pas de quel dossier "xxunit" tu parles. Je pense qu’un README.md dans le dossier tests sera suffisant.

[kwizer15]

@Mips2648 je viens de rajouter un commit avec les quelques modifications que tu m’as proposé, et une documentation pour les tests que j’espère suffisamment explicite.

[kwizer15]

@Hotfirenet Est-ce qu’il est utile que je refasse cette MR en plusieurs étapes ?

• Réactivation des tests existants
• Ajout des tests BC
• Ajout des tests BDD
• Refacto BDD

Je dois pouvoir faire sans l’ajout du fichier .env qui semble être sujet à débat.

Ça m’a demandé pas mal de travail, et j’ai pas envie d’y repasser du temps pour rien.