Ce n'est plus à démontrer : les tests unitaires sont incontournables dans le développement d'une application. Ils permettent de mettre en évidence d'éventuelles régressions apportées lors de modifications du code, et donc au développeur d'acquérir une certaine confiance à mettre le code en production : si les tests passent, c'est que tout fonctionne correctement.
-Pour mesurer cette confiance, on utilise principalement comme métrique la couverture de code. Plus la couverture est grande (proche de 100%), moins il y a de chances qu'une régression passe entre les mailles du filet.
-Mais attention ! Cette affirmation n'est que purement théorique !
Nous allons voir que dans certains cas la couverture de code n'est qu'un faux indicateur de protection.
-Voici un exemple simple :
<?php
-
-class Astronaut {}
-
-class SpaceShip
-{
- private $capacity;
- public $astronauts = [];
-
- public function __construct($capacity)
- {
- $this->capacity = $capacity;
- }
-
- public function addAstronaut(Astronaut $astronaut)
- {
- if (count($this->astronauts) < $this->capacity) {
- $this->astronauts[] = $astronaut;
- }
- }
-}
-
-Ici notre classe SpaceShip a une méthode publique addAstronaut qui ajoute une instance de Astronaut uniquement si la capacité maximale n'est pas atteinte.
-Voyons un exemple de test unitaire associé :
<?php
-
-class SpaceShipTest extends \PHPUnit_Framework_TestCase
-{
- public function testAddAstronaut()
- {
- $spaceShip = new SpaceShip(1);
-
- $spaceShip->addAstronaut(new Astronaut());
-
- $this->assertCount(1, $spaceShip->astronauts);
- }
-}
-
-Le test vérifie ici que la méthode ajoute bien une entrée au tableau d'astronautes. En lançant les tests nous avons une couverture de 100% (même sans assertion nous aurions eu ce résultat).
-Mais nous ne sommes pas protégés pour autant : que se passerait-il si la méthode addAstronaut changeait ?
-Notre test suffira-t-il à détecter une régression ?
Pour détecter les failles dans vos tests unitaires, il existe une solution : les tests de mutation.
-Le principe est simple : altérer le code source pour vérifier que les tests associés échouent en conséquence.
-Afin d'y parvenir, voici les étapes nécessaires :
Évidemment, pas la peine de faire tout ça à la main, il existe des frameworks qui vont s'en occuper pour nous.
-Mais avant de voir ça de plus près, voici un peu de vocabulaire :
-Ici nous utiliserons Humbug, un framework parmi d'autres qui permet de faire des tests de mutation en PHP.
-Lorsque nous lançons Humbug avec notre exemple de tout à l'heure, nous obtenons :
-$> humbug -... -Mutation Testing is commencing on 1 files... -(.: killed, M: escaped, S: uncovered, E: fatal error, T: timed out) - -M. - -2 mutations were generated: - 1 mutants were killed - 0 mutants were not covered by tests - 1 covered mutants were not detected - 0 fatal errors were encountered - 0 time outs were encountered - -Metrics: - Mutation Score Indicator (MSI): 50% - Mutation Code Coverage: 100% - Covered Code MSI: 50% --
Diantre ! Un mutant nous a échappé ! Voyons dans le fichier de de log :
-1) \Humbug\Mutator\ConditionalBoundary\LessThan
-Diff on \SpaceShip::addAstronaut() in src/SpaceShip.php:
---- Original
-+++ New
-@@ @@
- {
-- if (count($this->astronauts) < $this->capacity) {
-+ if (count($this->astronauts) <= $this->capacity) {
- $this->astronauts[] = $astronaut;
- }
- }
- }
-
-Nos tests n'ont pas détecté le changement d'opérateur de comparaison. En effet, nous n'avons pas testé le cas où notre vaisseau spatial est plein. À présent, ajoutons un test pour couvrir ce use-case :
-<?php
-
-class SpaceShipTest extends \PHPUnit_Framework_TestCase
-{
- public function testAddsAstronautWhenShipNotFull()
- {
- $spaceShip = new SpaceShip(1);
-
- $spaceShip->addAstronaut(new Astronaut());
-
- $this->assertCount(1, $spaceShip->astronauts);
- }
-
- public function testDoesNotAddAstronautWhenShipFull()
- {
- $spaceShip = new SpaceShip(0);
-
- $spaceShip->addAstronaut(new Astronaut());
-
- $this->assertCount(0, $spaceShip->astronauts);
- }
-}
-
-Maintenant relançons Humbug :
-$> humbug -... -Mutation Testing is commencing on 1 files... -(.: killed, M: escaped, S: uncovered, E: fatal error, T: timed out) - -.. - -2 mutations were generated: - 2 mutants were killed - 0 mutants were not covered by tests - 0 covered mutants were not detected - 0 fatal errors were encountered - 0 time outs were encountered - -Metrics: - Mutation Score Indicator (MSI): 100% - Mutation Code Coverage: 100% - Covered Code MSI: 100% --
Et voilà, cette fois aucun mutant ne s'est échappé, notre suite de tests est vraiment efficace, ce bug éventuel n'arrivera jamais jusqu'à la production !
-Evidemment, l'exemple choisi ici est volontairement simple et n'est pas très évocateur, mais dans le code métier au cœur de votre application, vous avez certainement des use-case beaucoup plus sensibles.
Pour parvenir à ses fins, Humbug est capable de générer tout un éventail de mutations :
-Je ne vais pas tout détailler ici, si vous voulez en savoir plus je vous invite à consulter la page GitHub du projet.
-Les tests de mutation sont un moyen simple et efficace de détecter la fiabilité des tests unitaires. La couverture de code n'est pas une métrique très fiable, un code peut être couvert à 100% sans une seule assertion !
-Nous avons vu avec Humbug que nous pouvons automatiser ces tests, il devient alors possible de les greffer dans notre workflow d'intégration continue. Attention toutefois au temps d'exécution qui grandit de manière exponentielle lorsque la base de code grandit, on utilisera en priorité les tests de mutation là où il y a un véritable enjeu : le code métier.
Bien que la plupart des développeurs PHP connaissent l'existence de xDebug, je me rends compte que bien peu l'utilisent réellement, et souvent se laissent tenter par la méthode "à l'ancienne" du "var_dump(); die;".
-Dans cet article je vais tenter de vous familiariser avec cet outil d'une incroyable utilité, qui vous fera gagner un temps fou pour débugger vos applications.
- -Le principe est assez simple : On place tout d'abord un ou plusieurs points d'arrêt dans le code, là où on veut interrompre l'exécution du script. Lorsque l'on accède à une URL via le navigateur, xDebug intercepte l'appel et déclenche une session de debug en notifiant l'IDE. On retrouve alors dans l'IDE la valeur des variables du scope courant ainsi que la pile d'appels. Le plus sympathique est de pouvoir avancer l'exécution pas à pas en naviguant dans les appels de fonctions tout en gardant un œil sur les valeurs des variables présentes dans le scope.
-Il est également possible de débugger les scripts en mode CLI. C'est exactement le même principe.
-Si ce n'est pas déjà le cas, il faut installer et activer l'extension xDebug.
-Sur ubuntu cela donne :
-$ sudo apt-get install php-xdebug --
Pour les autres systèmes je vous invite à voir la documentation officielle.
-Normalement l'extension doit maintenant être chargée avec PHP :
-$ php -m | grep xdebug -xdebug --
Vous aurez également besoin d'un IDE, ici nous verrons un exemple avec PHPStorm, mais bien d'autres sont compatibles en installant simplement un plugin (NetBeans, Atom, SublimeText, etc...)
-Dans cette section nous verrons comment utiliser xDebug avec votre IDE pour débugger une application web sur un serveur distant (ou même en local).
-Pour activer le debug distant, nous avons besoin de modifier la config php.ini :
-xdebug.remote_enable=On # Activer le debug distant -xdebug.remote_connect_back=On # xDebug va automatiquement se connecter sur l'IP présente dans $_SERVER['REMOTE_ADDR'] -xdebug.remote_host=localhost # Host à contacter si remote_connect_back est désactivé ou dans un contexte CLI -xdebug.remote_port=9000 # Port par défaut -xdebug.idekey=idekey # Identifiant de session utilisé par l'IDE --
Ensuite, configurons PHPStorm :
-On va dans Run > Edit configurations, puis cliquer sur le symbole "+"
-Dans la liste on clique sur "PHP Remote Debug".
Nommez votre configuration et renseignez l'idekey, ici "idekey" comme configuré dans le php.ini.
-On ajoute ensuite un serveur en cliquent sur le bouton "..."
Dans cet exemple je fais tourner un server en local, mon host distant est en fait localhost. On laisse le port 80 et on sélectionne évidemment "xDebug". Il faut également mapper les fichiers PHP locaux avec ceux qui se trouvent sur le serveur (pour que l'IDE reconnaisse les fichiers que xDebug lui communique). Ici mon projet se trouve dans /var/www sur le serveur distant.
-Maintenant il ne nous reste plus qu'à poser un point d'arrêt dans le code et d'écouter les connections de xDebug (bouton à droite sur l'image) :
Pour déclencher la session de debug, nous devons passer la variable XDEBUG_SESSION_START en query string avec comme valeur notre idekey.
-
-Il est également possible de passer par un cookie, mais le plus simple est d'utiliser un plugin sur votre navigateur (Xdebug helper pour chrome, The easiest debug pour firefox) qui vous permet en un clic d'activer le debugging.
Et HOP ! PHPStorm surgit tout à coup et nous montre tout ce qui se passe à l'endroit de notre point d'arrêt !
-On peut même avancer l'exécution au pas à pas !
Pour utiliser xDebug sur un script CLI (exécuter un simple fichier PHP ou une commande Symfony par exemple), la démarche est exactement la même. Mais cette fois xDebug ne peut plus déterminer sur quelle IP se connecter pour lancer la session de debug. La propriété xdebug.remote_connect_back n'est d'aucune utilité. Nous devons spécifier sur quel hôte nous voulons être contactés en utilisant la propriété xdebug.remote_host (localhost par défaut).
-Voici à quoi ressemble notre configuration php.ini (celui du CLI cette fois) :
-xdebug.remote_enable=On # Activer le debug distant -xdebug.remote_host=localhost # Host à contacter (obligatoire en mode CLI) -xdebug.remote_port=9000 # Port par défaut -xdebug.idekey=idekey # Identifiant de session utilisé par l'IDE --
La configuration reste similaire, mais en mode CLI nous ne voulons pas forcément lancer du debug à chaque commande PHP. Je vous conseille plutôt de ne pas activer le remote debugging dans le php.ini, mais directement en lançant la commande PHP :
-$ export XDEBUG_CONFIG="remote_enable=1" # Démarrage de la session -$ php bin/console xdebug:test -... -$ unset XDEBUG_CONFIG # Fin de session --
Ou encore :
-$ XDEBUG_CONFIG="remote_enable=1" php bin/console xdebug:test --
Pour débugger en mode CLI sur un serveur distant, vous devez simplement changer la valeur de xdebug.remote_host dans le php.ini par votre IP.
-L'utilisation de xDebug ne demande pas 5 ans d'études ! Alors utilisez-le, vu l'énorme gain de temps qu'il apporte par rapport à du debug à la main, que ce soit en web ou en CLI, en local ou sur un serveur distant, vous n'avez plus d'excuse !
-{% endraw %} diff --git a/_posts/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires.md b/_posts/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires.md new file mode 100644 index 000000000..764107260 --- /dev/null +++ b/_posts/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires.md @@ -0,0 +1,209 @@ +--- +layout: post +title: Mutation Testing – Vérifiez la qualité de vos tests unitaires +excerpt: Vos tests unitaires sont-ils fiables ? Dans cet article nous allons voir comment s’en assurer +author: rgraillon +date: '2016-10-19 13:28:19 +0100' +date_gmt: '2016-10-19 14:28:19 +0100' +permalink: /fr/mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires/ +categories: + - test + - php +tags: + - test + - php +image: + path: /assets/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires/DNA.jpg + height: 100 + width: 100 +--- + +## Les Tests Unitaires et la confiance + +Ce n’est plus à démontrer : les tests unitaires sont incontournables dans le développement d’une application. Ils permettent de mettre en évidence d’éventuelles régressions apportées lors de modifications du code, et donc au développeur d’acquérir une certaine confiance à mettre le code en production : si les tests passent, c’est que tout fonctionne correctement. + +Pour mesurer cette confiance, on utilise principalement comme métrique la couverture de code. Plus la couverture est grande (proche de 100%), moins il y a de chances qu’une régression passe entre les mailles du filet. +Mais attention ! Cette affirmation n’est que purement théorique ! + +## Couverture vs Protection + +Nous allons voir que dans certains cas la couverture de code n’est qu’un faux indicateur de protection. +Voici un exemple simple : + +```php +capacity = $capacity; + } + + public function addAstronaut(Astronaut $astronaut) + { + if (count($this->astronauts) < $this->capacity) { + $this->astronauts[] = $astronaut; + } + } +} +``` + +Ici notre classe `SpaceShip` a une méthode publique `addAstronaut` qui ajoute une instance de `Astronaut` uniquement si la capacité maximale n’est pas atteinte. +Voyons un exemple de test unitaire associé : + +```php +addAstronaut(new Astronaut()); + + $this->assertCount(1, $spaceShip->astronauts); + } +} +``` + +Le test vérifie ici que la méthode ajoute bien une entrée au tableau d’astronautes. En lançant les tests nous avons une couverture de 100% (même sans assertion nous aurions eu ce résultat). +Mais nous ne sommes pas protégés pour autant : que se passerait-il si la méthode `addAstronaut` changeait ? +Notre test suffira-t-il à détecter une régression ? + +## Tests de Mutation + +Pour détecter les failles dans vos tests unitaires, il existe une solution : **les tests de mutation**. + +Le principe est simple : altérer le code source pour vérifier que les tests associés échouent en conséquence. +Afin d’y parvenir, voici les étapes nécessaires : + +- Lancer la suite de tests une première fois pour vérifier que tous les tests passent (il est inutile d’essayer de faire échouer un test qui échoue déjà !) +- Relancer la suite en modifiant certaines parties du code testé. +- Vérifier que les tests échouent lorsque le code testé a subi une mutation. +- Recommencer autant de fois qu’il y a de mutations possibles. +Évidemment, pas la peine de faire tout ça à la main, il existe des frameworks qui vont s’en occuper pour nous. + +Mais avant de voir ça de plus près, voici un peu de vocabulaire : + +- **Mutant** : Altération unitaire du code (ex: un `!==` remplacé par un `===`) +- **Killed/Captured** : On dit qu’un mutant est tué si le test unitaire échoue (résultat positif) +- **Escaped** : Un mutant s’échappe si le test unitaire n’échoue pas (résultat négatif) +- **Uncovered** : Un mutant n’est pas couvert si aucun test ne couvre le code qui porte le mutant. + +## Mise en pratique avec Humbug + +Ici nous utiliserons [Humbug](https://github.com/padraic/humbug), un framework parmi d’autres qui permet de faire des tests de mutation en PHP. + +Lorsque nous lançons Humbug avec notre exemple de tout à l’heure, nous obtenons : + +```bash +humbug +... +Mutation Testing is commencing on 1 files... +(.: killed, M: escaped, S: uncovered, E: fatal error, T: timed out) + +M. + +2 mutations were generated: + 1 mutants were killed + 0 mutants were not covered by tests + 1 covered mutants were not detected + 0 fatal errors were encountered + 0 time outs were encountered + +Metrics: + Mutation Score Indicator (MSI): 50% + Mutation Code Coverage: 100% + Covered Code MSI: 50% +``` + +Diantre ! Un mutant nous a échappé ! Voyons dans le fichier de de log : + +```diff +1) \Humbug\Mutator\ConditionalBoundary\LessThan +Diff on \SpaceShip::addAstronaut() in src/SpaceShip.php: +--- Original ++++ New +@@ @@ + { +- if (count($this->astronauts) < $this->capacity) { ++ if (count($this->astronauts) <= $this->capacity) { + $this->astronauts[] = $astronaut; + } + } + } +``` + +Nos tests n’ont pas détecté le changement d’opérateur de comparaison. En effet, nous n’avons pas testé le cas où notre vaisseau spatial est plein. À présent, ajoutons un test pour couvrir ce use-case : + +```php +addAstronaut(new Astronaut()); + + $this->assertCount(1, $spaceShip->astronauts); + } + + public function testDoesNotAddAstronautWhenShipFull() + { + $spaceShip = new SpaceShip(0); + + $spaceShip->addAstronaut(new Astronaut()); + + $this->assertCount(0, $spaceShip->astronauts); + } +} +``` + +Maintenant relançons Humbug : + +```bash +humbug +... +Mutation Testing is commencing on 1 files... +(.: killed, M: escaped, S: uncovered, E: fatal error, T: timed out) + +.. + +2 mutations were generated: + 2 mutants were killed + 0 mutants were not covered by tests + 0 covered mutants were not detected + 0 fatal errors were encountered + 0 time outs were encountered + +Metrics: + Mutation Score Indicator (MSI): 100% + Mutation Code Coverage: 100% + Covered Code MSI: 100% +``` + +Et voilà, cette fois aucun mutant ne s’est échappé, notre suite de tests est vraiment efficace, ce bug éventuel n’arrivera jamais jusqu’à la production ! +Evidemment, l’exemple choisi ici est volontairement simple et n’est pas très évocateur, mais dans le code métier au cœur de votre application, vous avez certainement des use-case beaucoup plus sensibles. + +Pour parvenir à ses fins, Humbug est capable de générer tout un éventail de mutations : + +- Remplacement d’opérateurs de comparaison (`>` par `>=`, `!==` par `===`, etc…) +- Remplacement de constantes (`0` par `1`, `true` par `false`, etc…) +- Remplacement des opérateurs logiques (`&&`, `||`, etc…) +- Remplacement des opérateurs binaires (`&`, `|`, `%`, etc…) +- Remplacement des valeurs de retour d’une fonction +Je ne vais pas tout détailler ici, si vous voulez en savoir plus je vous invite à consulter la [page GitHub du projet](https://github.com/padraic/humbug). + +## Conclusion + +Les tests de mutation sont un moyen simple et efficace de détecter la fiabilité des tests unitaires. La couverture de code n’est pas une métrique très fiable, un code peut être couvert à 100% sans une seule assertion ! +Nous avons vu avec Humbug que nous pouvons automatiser ces tests, il devient alors possible de les greffer dans notre workflow d’intégration continue. Attention toutefois au temps d’exécution qui grandit de manière exponentielle lorsque la base de code grandit, on utilisera en priorité les tests de mutation là où il y a un véritable enjeu : le code métier. diff --git a/_posts/2016-12-15-debugger-avec-xdebug.md b/_posts/2016-12-15-debugger-avec-xdebug.md new file mode 100644 index 000000000..22f4d0073 --- /dev/null +++ b/_posts/2016-12-15-debugger-avec-xdebug.md @@ -0,0 +1,123 @@ +--- +layout: post +title: Débugger avec xDebug +excerpt: Dans cet article je vais tenter de vous familiariser avec xDebug, cet outil d'une incroyable utilité, qui vous fera gagner un temps fou pour débugger vos applications. +author: rgraillon +date: '2016-12-15 14:49:00 +0100' +date_gmt: '2016-12-15 15:49:00 +0100' +permalink: /fr/debugger-avec-xdebug/ +categories: + - php +tags: + - php +image: + path: /assets/2016-12-15-debugger-avec-xdebug/php-bug.jpg + height: 100 + width: 100 +--- + +Bien que la plupart des développeurs PHP connaissent l'existence de xDebug, je me rends compte que bien peu l'utilisent réellement, et souvent se laissent tenter par la méthode « à l'ancienne » du `var_dump(); die;`. + +Dans cet article je vais tenter de vous familiariser avec cet outil d'une incroyable utilité, qui vous fera gagner un temps fou pour débugger vos applications. + +## Les bases + +Le principe est assez simple : On place tout d'abord un ou plusieurs points d'arrêt dans le code, là où on veut interrompre l'exécution du script. Lorsque l'on accède à une URL via le navigateur, xDebug intercepte l'appel et déclenche une session de debug en notifiant l'IDE. On retrouve alors dans l'IDE la valeur des variables du scope courant ainsi que la pile d'appels. Le plus sympathique est de pouvoir avancer l'exécution pas à pas en naviguant dans les appels de fonctions tout en gardant un œil sur les valeurs des variables présentes dans le scope. + +Il est également possible de débugger les scripts en mode CLI. C'est exactement le même principe. + +## Prérequis + +Si ce n'est pas déjà le cas, il faut installer et activer l'extension xDebug. + +Sur ubuntu cela donne : + +```bash +sudo apt-get install php-xdebug +``` +Pour les autres systèmes je vous invite à voir la documentation officielle. + +Normalement l'extension doit maintenant être chargée avec PHP : + +```bash +php -m | grep xdebug +xdebug +``` + +Vous aurez également besoin d'un IDE, ici nous verrons un exemple avec PHPStorm, mais bien d'autres sont compatibles en installant simplement un plugin (NetBeans, Atom, SublimeText, etc...) + +## Remote debugging (web) + +Dans cette section nous verrons comment utiliser xDebug avec votre IDE pour débugger une application web sur un serveur distant (ou même en local). + +Pour activer le debug distant, nous avons besoin de modifier la config php.ini : + +```ini +xdebug.remote_enable=On # Activer le debug distant +xdebug.remote_connect_back=On # xDebug va automatiquement se connecter sur l'IP présente dans $_SERVER['REMOTE_ADDR'] +xdebug.remote_host=localhost # Host à contacter si remote_connect_back est désactivé ou dans un contexte CLI +xdebug.remote_port=9000 # Port par défaut +xdebug.idekey=idekey # Identifiant de session utilisé par l'IDE +``` +Ensuite, configurons PHPStorm : + +On va dans **Run > Edit configurations**, puis cliquer sur le symbole « + » +Dans la liste on clique sur « **PHP Remote Debug** ». + + + +Nommez votre configuration et renseignez l'idekey, ici « idekey » comme configuré dans le php.ini. +On ajoute ensuite un serveur en cliquent sur le bouton « ... » + + + +Dans cet exemple je fais tourner un server en local, mon host distant est en fait localhost. On laisse le port **80** et on sélectionne évidemment « **xDebug** ». Il faut également mapper les fichiers PHP locaux avec ceux qui se trouvent sur le serveur (pour que l'IDE reconnaisse les fichiers que xDebug lui communique). Ici mon projet se trouve dans **/var/www** sur le serveur distant. + +Maintenant il ne nous reste plus qu'à poser un point d'arrêt dans le code et d'écouter les connections de xDebug (bouton à droite sur l'image) :  + + + +Pour déclencher la session de debug, nous devons passer la variable `XDEBUG_SESSION_START` en query string avec comme valeur notre idekey. + + +> Il est également possible de passer par un cookie, mais le plus simple est d'utiliser un plugin sur votre navigateur ([Xdebug helper](https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc) pour chrome, [The easiest debug](https://addons.mozilla.org/fr/firefox/addon/the-easiest-xdebug/) pour firefox) qui vous permet en un clic d'activer le debugging. + +Et HOP ! PHPStorm surgit tout à coup et nous montre tout ce qui se passe à l'endroit de notre point d'arrêt ! +On peut même avancer l'exécution au pas à pas ! + + + +## Debugger les scripts CLI + +Pour utiliser xDebug sur un script CLI (exécuter un simple fichier PHP ou une commande Symfony par exemple), la démarche est exactement la même. Mais cette fois xDebug ne peut plus déterminer sur quelle IP se connecter pour lancer la session de debug. La propriété `xdebug.remote_connect_back` n'est d'aucune utilité. Nous devons spécifier sur quel hôte nous voulons être contactés en utilisant la propriété `xdebug.remote_host` (localhost par défaut). + +Voici à quoi ressemble notre configuration php.ini (celui du CLI cette fois) : + +```ini +xdebug.remote_enable=On # Activer le debug distant +xdebug.remote_host=localhost # Host à contacter (obligatoire en mode CLI) +xdebug.remote_port=9000 # Port par défaut +xdebug.idekey=idekey # Identifiant de session utilisé par l'IDE +``` + +La configuration reste similaire, mais en mode CLI nous ne voulons pas forcément lancer du debug à chaque commande PHP. Je vous conseille plutôt de ne pas activer le remote debugging dans le php.ini, mais directement en lançant la commande PHP : + +```bash +export XDEBUG_CONFIG="remote_enable=1" # Démarrage de la session +php bin/console xdebug:test +... +unset XDEBUG_CONFIG # Fin de session +``` +Ou encore : + +```bash +XDEBUG_CONFIG="remote_enable=1" php bin/console xdebug:test +``` + + + +Pour débugger en mode CLI sur un serveur distant, vous devez simplement changer la valeur de `xdebug.remote_host` dans le php.ini par votre IP. + +## Conclusion + +L'utilisation de xDebug ne demande pas 5 ans d'études ! Alors utilisez-le, vu l'énorme gain de temps qu'il apporte par rapport à du debug à la main, que ce soit en web ou en CLI, en local ou sur un serveur distant, vous n'avez plus d'excuse ! diff --git a/assets/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires/DNA.jpg b/assets/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires/DNA.jpg new file mode 100644 index 000000000..5a3c61082 Binary files /dev/null and b/assets/2016-10-19-mutation-testing-verifiez-la-qualite-de-vos-tests-unitaires/DNA.jpg differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/browser.png b/assets/2016-12-15-debugger-avec-xdebug/browser.png new file mode 100644 index 000000000..d1ff1bc1b Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/browser.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/configuration_dropdown.png b/assets/2016-12-15-debugger-avec-xdebug/configuration_dropdown.png new file mode 100644 index 000000000..36cb4cf3f Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/configuration_dropdown.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/debugging.png b/assets/2016-12-15-debugger-avec-xdebug/debugging.png new file mode 100644 index 000000000..6017f977d Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/debugging.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/debugging_cli.png b/assets/2016-12-15-debugger-avec-xdebug/debugging_cli.png new file mode 100644 index 000000000..16854be05 Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/debugging_cli.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/my_app_remote.png b/assets/2016-12-15-debugger-avec-xdebug/my_app_remote.png new file mode 100644 index 000000000..d3439b269 Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/my_app_remote.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/my_controller.png b/assets/2016-12-15-debugger-avec-xdebug/my_controller.png new file mode 100644 index 000000000..fa541e143 Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/my_controller.png differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/php-bug.jpg b/assets/2016-12-15-debugger-avec-xdebug/php-bug.jpg new file mode 100644 index 000000000..d0babaa0b Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/php-bug.jpg differ diff --git a/assets/2016-12-15-debugger-avec-xdebug/remote_host.png b/assets/2016-12-15-debugger-avec-xdebug/remote_host.png new file mode 100644 index 000000000..ea353c7e3 Binary files /dev/null and b/assets/2016-12-15-debugger-avec-xdebug/remote_host.png differ