GLPI 9.1.4 AVAILABLE

After several weeks, Teclib’ is happy to announce the release of GLPI 9.1.4.
You can download the 9.1.4 archive on github.

You’ll find below the most important changes of this bugfixes version:

– fix display regression on tickets tab of assets (#2151),
– fix ‘Location’ response header from API (#2211),
– change ticket validation link search criteria (#2154),
– add missing informations in contracts notifications (#68),
– fix link with items from ticket main form (#2127),
– fix date for monthly TCO calculation (#2171),
– fix “rn” issue on tickets solutions (#1944),
– no longer change author on task/followup edition (#2161),
– fix components items creation (#2172),
– add missing PHP extensions check at install (#981).

The full changelog is available here for more details.

We’d like to thank all people who contributed to this new version and all those who contribute regularly to the GLPI project.

GLPI 9.1.4 DISPONIBLE

Après plusieurs semaines de développement, Teclib’ a le plaisir de vous annoncer la sortie de GLPI version 9.1.4.
L’archive de la version 9.1.4 est disponible sur github

Vous trouverez ci-dessous la liste des changements les plus importants de cette version corrective :

– correction d’une régression d’affichage de l’onglet tickets dans les éléments d’inventaire (#2151),
– correction de l’entête de réponse ‘Location’ de l’API (#2211),
– changement des critères de recherche du lien de validation des tickets (#2154),
– ajout d’informations manquantes dans les notifications des contrats (#68),
– correction du lien avec les éléments depuis le formulaire principal du ticket (#2127),
– correction de la date pour les calculs mensuels de cycle de vie (TCO) (#2171),
– correction du problème “rn” sur les solutions des tickets (#1944),
– ne plus modifier l’auteur lors de la modification d’une tâche ou d’un suivi (#2161),
– correction de la création de composants (#2172),
– ajout de la vérification de certaines extensions PHP manquantes à l’installation (#981).

Voir le journal des changements complet pour plus de détails

Nous remercions toutes les personnes qui ont contribué à cette nouvelle version et plus généralement toutes celles et ceux qui soutiennent régulièrement le projet GLPI.

Glpi now uses atoum for its unit tests!

About 2 years ago, we’ve begin to add some unit tests in the GLPI project; thanks to Valentin and Remi Collet. The PHPUnit framework has been used, since this is the most “common” choice for a PHP project.

Unfortunately, many parts of the code are not tested yet… This is a huge job; but we’re working on it. Nowadays, each new feature implemented in GLPI is unit tested; and we plan to spend time this summer to work on all of this.

Why now?

I personally appreciate atoum since its very beginning, and I’ve proposed to switch a while ago. Since we plan to add more and more tests; switching while there are still a few tests was easier. That’s why it’s been done now.

So, why to switch?

Well… Speaking of PHP unit testing frameworks, there are not so many possible choices. PHPunit is probably the oldest unit testing framework available for PHP; and it does the job, really. atoum is a more recent and modern choice, and it has some interesting capabilities:

  • testing variables types (if you test an integer and get a string, this is not correct),
  • wonderful mocking system (that permit to mock php native functions, constants, …),
  • use closure to test outputs, exceptions, … (way more interesting than phpunit’s annotations),
  • concurrent run of tests (even if it have been disabled for GLPI),
  • fully isolated tests,
  • chained calls,
  • more natural way to write tests (this is maybe just my point of view – but this is really more simple to me).

Also, GLPI is a French project, most core team members are French, just as atoum! 😉

On a technical note

Switching from PHPUnit to atoum is not something very difficult, especially if you did not yet use advanced features (which is the case for GLPI); but it is not really something that can be scripted. In facts, it could for some common cases, but reviewing tests is not something bad globally. Also, re-writing tests is a very good start point to learn new syntax, asserters and possibilities.

For the GLPI project, we’ve spent two days working on the rewrite. What we had to take care of:

  • atoum is not permissive at all. Every notice in the code will make tests fail per default (which is a good point); we had to fix them;
  • we’re doing kind of functional tests and not only unit tests. Some existing tests used to change existing values in the database, before resetting them. That cannot be done running tests concurrently;
  • atoum does not support dependencies across tests; which phpunit does. It should seem a bad point, but the point is “tests are isolated”. So… They cannot be dependent, we had to find another way;
  • session usage: GLPI uses many data in the session; and that is really a problem for testing… We had to disable concurrent runs mainly because of that :’(

The future

In a close future, we plan to improve our unit tests; since many parts of the code are not tested at all. We also plan to split our unique directory into several ones, making possible to disable concurrent runs only on functional tests, not on the whole tests suite.

Johan Cwiklinski.

GLPI utilise désormais atoum pour ses tests unitaires !

Il y a approximativement 2 ans, nous avons commencé à ajouter quelques tests unitaires dans le projet GLPI ; grâce à Valentin et Remi Collet. Le framework PHPUnit avait été retenu, puisqu’il s’agit du choix le plus “commun” pour un projet PHP.

Malheureusement, de nombreuses parties du code ne sont pas encore testées… C’est une très grosse tâche ; mais nous y travaillons. Actuellement, toute nouvelle fonctionnalité implémentée dans GLPI est pourvue de tests unitaires ; et nous prévoyons de passer du temps cet été pour travailler sur tout cela.

Pourquoi maintenant ?

J’apprécie personnellement atoum depuis ses tout débuts, j’ai proposé la migration il y a un certain temps. Puisque nous prévoyons l’ajout de plus en plus de tests ; la migration était plus facile tant qu’il y en a encore relativement peu. Voilà pourquoi ça a été fait maintenant.

Donc, pourquoi migrer ?

Et bien… S’agissant de framework de tests unitaires en PHP, il n’y a pas tant de choix possibles. PHPUnit est probablement le plus ancien framework de tests unitaires disponible en PHP ; et il fait son travail, pas de problèmes. atoum représente une choix plus récent et moderne, il possède aussi quelques possibilités fort intéressantes :

  • test des types de variables (si vous testez un entier et obtenez une chaîne de caractères, ce n’est pas correct),
  • merveilleux système de bouchonnage (qui permet de bouchonner les fonctions natives de PHP, des constantes, …),
  • utilisation de fonctions anonymes pour tester les sorties, les exceptions, … (bien plus intéressant que les annotations de phpunit),
  • lancement concurrent des tests (bien que ceci ait été désactivé pour GLPI),
  • tests entièrement isolés,
  • appels chaînés,
  • écriture des tests davantage naturelle (il ne s’agit peut être que de mon point de vue – mais ça me semble vraiment plus simple).

De plus, GLPI est un projet français, la plupart des membres du cœur sont français, tout comme atoum ! 😉

Sur une note technique

Passer de PHPUnit à atoum n’est pas quelque chose de très complexe, surtout si vous n’avez pas utilisé de fonctionnalités très avancées (ce qui est le cas pour GLPI) ; mais cela ne peut pas vraiment être automatisé. En fait, si, ce serait possible pour certains cas communs, mais revoir les tests n’est globalement pas plus mal. Aussi, ré-écrire les tests est un excellent point de départ pour apprendre la nouvelle syntaxe, les assertions et les possibilités offertes.

Pour le projet GLPI, nous avons passé deux jours à travailler sur cette réécriture. Voici ce à quoi nous avons du prêter attention :

  • atoum n’est pas du tout permissif. Toute notice dans le code fait échouer les tests par défaut (ce qui est une bonne chose) ; nous avons du les corriger ;
  • nous réalisons plutôt des tests fonctionnels et pas seulement unitaires. Certains tests existants modifiaient les valeurs existant en base avant de les réinitialiser. Ce n’est pas possible lorsque les tests sont lancés de manière concurrente ;
  • atoum ne permet pas de rendre des tests dépendants d’autres tests ; ce que permet phpunit. Cela pourrait ressembler à un point négatif, mais “les tests sont isolés”. Donc… Ils ne peuvent être inter-dépendants, nous avons du trouver d’autres solutions ;
  • utilisation des sessions : GLPI utilise de nombreuses données stockées en session ; et cela pose un réel problème pour les tests… Nous avons du désactiver la concurrence des tests à cause de ça :’(

Le futur

Dans un futur proche, nous prévoyons d’améliorer nos tests unitaires ; puisque de nombreuses parties du code ne sont pas testées du tout. Nous prévoyons aussi de scinder notre dossier unique en plusieurs, rendant ainsi possible de ne désactiver la concurrence uniquement sur les tests fonctionnels et pas sur la suite entière.

Johan Cwiklinski.