Le blogue d'Infoglobe

C'est votre première visite ici ! Peut être voudriez-vous souscrire à notre fil RSS pour connaître tous les changements. Merci pour votre visite !

Lorsque nous développons de nouvelles fonctionnalités dans notre code, il nous arrive de se demander si une modification viendra en briser une autre créée antérieurement. Afin de s’assurer de la stabilité de notre composante, il est impératif d’avoir un système qui nous assure que les fonctionnalités implémentées auparavant n’aient pas été supprimées. PHPUnit à la rescousse!

PHPUnit permet de tester nos blocs de code indépendamment les uns des autres. Lors de la création d’un test de fonctionnalité, nous devons donner une valeur à notre fonction. PHPUnit s’assurera que la valeur retournée par la fonction sera la valeur attendue. Plus la fonction sera étendue afin de supporter de nouveaux paramètres, plus les tests nous permettront de nous assurer qu’aucune fonctionnalité précédemment développée ne sera brisée.

Installation

Le mode d’installation à été trouvé sur PHPUnit.de. Il nous permet d’installer la version via les canaux PEAR.

Installer xdebug

Installer PHPUnit

sudo pear channel-discover pear.phpunit.de

sudo pear install –alldeps phpunit/PHPUnit

Une fois que PHPUnit est installé et fonctionnel, vous êtes prêt à créer votre premier test. Idéalement, si vous utilisez une librairie ou un framework, vous voudrez sans doute vouloir configurer vos tests afin que chacun utilise les classes de votre librairie. Pour cela, je vous suggère de vous créer une classe qui servira de « bootstrap » et qui sera appelée avant chaque test.

Voici un exemple de « bootstrap ».

setup.php

class Setup {

public static function init() {

// Root, libraries, classes and tests directories.
$root       = dirname(dirname(__FILE__));
$config     = $root} . ‘/config’;
$librairies = $root . ‘/libraries’;
$tests      = $root . ‘/tests’;

// Empêche le coverage du dossier de tests.
PHPUnit_Util_Filter::addDirectoryToFilter($tests);

// Update include path.
$path = array($config, $librairies, $tests, get_include_path());
set_include_path(implode(PATH_SEPARATOR, $path));

// Add files to the PHPUnit code coverage whitelist.
if (version_compare(PHPUnit_Runner_Version::id(), ’3.1.6′, ‘>=’)) {
PHPUnit_Util_Filter::addDirectoryToWhitelist($starLib);

}

}

Votre classe de test

Blog.php

require_once ‘PHPUnit/Framework.php’;
//require_once dirname(__FILE__) . ‘/setup.php’;

class Blog extends PHPUnit_Framework_TestCase {

public function test_failed() {

$this->assertFalse(true, ‘Ce test ne fonctionne pas’);

}

public function test_success() {

$this->assertTrue(true, ‘Ce test fonctionne’);

}

}

Une fois ces étapes réalisées, vous n’avez qu’à exécuter le fichier Blog.php pour obtenir ce résultat:

phpunit –colors Blog.php

Pour plus d’informations sur l’utilisation de PHPUnit, voir sur le site .

Bon test !

       Ça vous dit quelque chose?

Dernièrement, j’ai tenté de mettre du code en production. C’est alors que ces caractères plutôt étranges sont apparus dans le haut de ma page. J’ai d’abord pensé que c’était un problème d’encodage. Je me suis donc mis à la recherche d’un saut de ligne ou d’un autre caractère qui pouvait être rendu avant le doctype. Il m’a fallu bien peu de temps pour me rendre compte que ces recherches ne règleraient en rien mon problème. J’ai donc regardé l’encodage des fichiers sur le serveur afin de les comparer avec l’encodage de la page dans Firefox. Mon constat : les deux étaient identiques, soit UTF-8.

J’ai alors eu l’idée d’utiliser le « valideur W3C»  afin de vérifier s’il n’y avait pas d’autres problèmes sur la page en question. À ma grande surprise, cette note est apparue:

Byte-Order Mark found in UTF-8 File

Le Byte-Order Mark permet aux programmes de comprendre que le texte est en UTF-8, UTF-16 ou UTF-32. Le BOM est un espace insécable de largeur nulle zero-width no-break space. Certains encodages tel que UTF-16 ont besoin des BOM pour bien fonctionner. Pour ce qui est de UTF-8, il n’est pas nécessaire et est plutôt mal supporté par les IDE. Par contre, certains programmes peuvent l’ajouter pour diverses raisons. Puisque les BOM ne sont pas visibles, nous sommes incapables de les remplacer avec un « search/replace ».

On peut corriger ce problème en utilisant un éditeur qui permet d’enregistrer un fichier dans un encodage sans BOM. En faisant quelques recherches sur le net, j’ai trouvé que Notepad++ nous offre cette possibilité. Dans l’éditeur, cliquez sur l’option UTF-8 without BOM dans le menu Encoding. Il ne vous restera qu’à sauvegarder votre fichier pour que le caractère ne s’affiche plus sur la page.

Voilà donc une bonne raison pour laquelle il vaut mieux utiliser des éditeurs standards pour tous les développeurs afin qu’aucun problème causé par une personne ne surgisse et bloque tous les autres développeurs.