[:fr]La parole est aux speakers : Charles Desneuf[:]

[:fr]Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

Écrire des tests pour le long terme

Début de projet, bonne résolution, cette fois on va faire des tests ! Au début tout se passe bien, puis petit à petit les tests commencent à devenir un frein au projet, ils prennent du temps à écrire, à s'exécuter, à modifier, virent au rouge à la moindre modification du code. Nous verrons entre autre comment organiser les tests, quels sont les pièges à éviter et comment améliorer leur lisibilité. Ces différentes techniques permettant d'améliorer la maintenabilité des tests et faire qu'ils aillent même jusqu'à servir de documentation.

Tu vas nous parler de tests automatisés au Forum PHP, te souviens-tu de tes premiers contacts avec ces outils/méthodologies ?

Je ne me souviens pas bien de la première fois mais je dirais qu’il s’agissait d’une réunion d’équipe où l’on a décidé de mettre en place des tests pour améliorer la qualité de ce que l’on produisait. Le but était vague et bien évidemment par manque de temps et de connaissance des outils et techniques, on n’a rien fait.
La seconde fois c’était certainement sur un projet où la majorité des tests consistaient à vérifier que les getters retournaient bien les valeurs passées au constructeur. On avait aussi pas mal de tests avec des mocks qui sautaient en permanence, c’était plus pénible qu’autre chose.
C’était d’un intérêt limité et on a assez vite arrêté de les maintenir.

(suite…)

[:fr]La parole est aux speakers : Remi Collet[:]

[:fr]Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

PHP 7.2

La version 7.2 devrait être publiée avant la fin de l'année. Présentation de cette nouvelle version et de ses nouveautés.

Comment devient-on release manager de PHP ?

Pour chaque version, 2 RM sont choisis par la communauté (après vote d’une RFC s’il y a plus de 2 candidats) parmi les contributeurs actifs. Pour moi, c’est une reconnaissance de mon activité de QA, en particulier lors des publications de versions (en lien avec les autres RM).

Le travail du RM consiste à s’assurer que la publication des nouvelles versions, de suivre les bugs, et les RFC et du respect des règles du projet (gel des fonctionnalités, stabilité, etc)

(suite…)