Au fil des flows

22août/135

Tester une application adossee a une base de donnee avec PHP Unit

Posted by Fabien Arcellier

Hier, j'ai écrit pour Vamos à la playa, une série de tests automatisés pour valider la partie serveur.

Au moment où j'écris ce billet, cette partie compte seulement 4 classes et un routeur. La partie serveur expose une API Restful qui compte une dizaine d'opération.

Le problème que je rencontrai depuis le départ, c'est quoi tester ? 90% du travail d'exposition des données consistent à récupérer les résultats en base et à les exposer au format json.

Qu'est ce que je teste ?

C'est naturellement que j'ai commencé à créer un projet de tests unitaires sous PHP Unit. J'ai réfléchi à 2 solutions :

  1. Encapsuler la récupération des données et écrire un bouchon pour les tests
  2. Considérer la base de donnée comme un composant logiciel avec un état

La solution 1 me posait un problème. Actuellement, Vamos est adossé à une base mysql. Vu le type d'application, c'est un choix raisonnable au départ du projet. C'est une techno maîtrisée et facile à mettre en oeuvre. A terme, si l'API évolue et que le projet grandit, il faudra envisager d'autres solutions techniques. La façon dont j'accède aux données présage nullement de la façon dont j'y accéderai demain. Si je conçois la partie DAO comme une partie indépendante et que je fige les interfaces, je fais un choix d'architecture prématurée.

Il reste donc la solution 2.

La base de donnee, un composant logiciel comme un autre

Vous vous demandez surement ce que j'entend par composant logiciel ? Un composant logiciel est une vue de l'esprit. Il traite des requêtes (qu'on peut généraliser par message) et modifie son état interne.

La base de donnée est un composant logiciel de mon application :

  • Elle exécute les requêtes de celle ci (SQL)
  • Elle modifie son état interne en conséquence

Si je ne maîtrise pas l'état de ce composant, aucune chance de pouvoir tester mon application.

Principe du test logiciel

Pour effectuer du test automatisé, un composant peut soit être remplacé par un bouchon (cas d'un test unitaire), soit être initialisé dans un état cohérent (cas pour un test fonctionnel).

J'ai écarté la première solution. Comment mettre en oeuvre la seconde de manière efficace ?

Le module DbUnit de PHPUnit

D'après ce que j'ai constaté, ce module répond à 2 besoins :

  • Initialiser une base de donnée à l'état voulu
  • Comparer l'état d'une base de donnée à un état attendu

Pour cela, le système s'appuie sur le concept de Dataset. Un dataset est une vue simplifiée des enregistrements présents dans les tables d'une base de donnée.

Ce concept s'appuie sur un autre format que le sql pour être plus facile à traiter.

Concrètement, voici un dataset au format xml :

<?xml version="1.0" encoding="UTF-8"?>
<!--
Dataset contains :
 * 2 playas
 * 4 olas
-->
<dataset>
  <table name="valp_beaches">
    <column>id</column>
    <column>name</column>
    <column>city</column>
    <column>latitude</column>
    <column>longitude</column>
    <column>modified</column>
    <column>created</column>
    <row>
      <value>1</value>
      <value>Playa 1</value>
      <value>City 1</value>
      <value>45.0</value>
      <value>45.0</value>
      <value>2013-08-24 17:15:23</value>
      <value>2013-04-24 17:15:23</value>
    </row>
    <row>
      <value>2</value>
      <value>Playa 2</value>
      <value>City 2</value>
      <value>46.0</value>
      <value>46.0</value>
      <value>2013-09-24 17:15:23</value>
      <value>2013-09-24 17:15:23</value>
    </row>
  </table>
  <table name="valp_beaches_gps" />
  <table name="valp_beaches_ondas">
    <column>id</column>
    <column>message</column>
    <column>created</column>
    <row>
      <value>1</value>
      <value>J'ai vu un requin</value>
      <value>2013-09-29 17:15:23</value>
    </row>
    <row>
      <value>2</value>
      <value>Ola 2</value>
      <value>2013-09-29 17:16:23</value>
    </row>

  </table>
</dataset>

Php unit utilise ce dataset pour :

  • Vider les tables qui y sont référencés
  • Les peupler avec les données

Pour utiliser cette feature, vous devez créer une classe de test qui hérite de PHPUnit_Extensions_Database_TestCase

class DatabaseTest extends \PHPUnit_Extensions_Database_TestCase {

  protected function getConnection() {
    $conf_database = array('connection_string' => 'mysql:host=127.0.0.1;dbname=mabase',
                            'user' => 'mabase_user',
                            'password' => 'mabase_password');

    $pdo = new \PDO($conf_database['connection_string'], 
            $conf_database['user'], 
            $conf_database['password'], 
            array(\PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8'));
    $pdo -> setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
    
    return $this->createDefaultDBConnection($pdo, ':memory:');
  }

  protected function getDataSet() {
    return $this->createXmlDataSet('datasets/playa_2_ola_2.xml');
  }

  public function testReadAll() {
    // ... Votre test
  }
}

J'ai simplifié ma classe de tests pour ce billet. Je vous renvoie à la documentation officielle pour avoir plus d'information sur les bonnes pratiques dans l'initialisation de votre base.

Avant d'exécuter le test DatabaseTest::testReadAll, PHP Unit initialisera la base avec les données provenant de notre dataset.

Pour conclure

Le mécanisme offert par PHP Unit permet de comparer une base après une opération qui a modifiée les données qu'elle contient avec un dataset.

A noter que sans utiliser cette extension, vous pouvez tout à fait initialiser votre base en utilisant un script sql exécuté dans la méthode setUp de votre classe de test. Cette solution vous privera de la possibilité de comparer le contenu de votre base avec un fichier dataset.

Remplis sous: Non classé 5 Commentaires
18nov/120

Parser des fichiers Xml de grande taille avec SAX

Posted by Fabien Arcellier

Dans certains contextes, vous pourriez à avoir à analyser des fichiers xml très volumineux. Un parser de type DOM est inefficace dans ce cas.

L'empreinte mémoire du fichier chargé peut dans des cas limites dépasser la capacité mémoire du serveur.

Dans ce cas, vous pouvez utiliser un autre type de parser. Ce mode d'analyse est décrit par l'acronyme SAX (Simple API for XML). L'idée derrière est de revenir aux fondamentaux. Il s'agit de voir le fichier xml comme un flux.

Vous envoyez ce flux vers le parser SAX. Il l'analyse et émet des événements quand il repère des motifs connus.

Il existe aussi une dernière forme de parser qui présente de nombreux avantages, les parsers de type PULL. J'en parle dans la conclusion.

Remplis sous: Non classé Lire la suite
6oct/120

Pour 2 millions et un parasol !!!

Posted by Fabien Arcellier

Logo de Vamos à la playa

J'avais écrit un premier billet a ce sujet. Je n'en étais pas satisfait, je trouvai qu'il manquait de profondeurs. Il n'exprimait pas l'expérience que j'ai eu la chance de vivre le week-end dernier. Voici la deuxième version :)

La Fing, en collaboration avec la région, organisait un hackathon sur 2 jours. Suite a la mise a disposition de donnees publiques (L'open data pour les inities), cet evenement avait pour but de promouvoir cette démarche et démontrer que cette ouverture vers un acteur tiers debouchera sur la creation de vrai services pour l'usager.

logo de Hack Data Paca

Un hackathon, qu'est ce que c'est ?

Pendant 2 jours, des personnes vont décider ensemble de porter un projet. Elles ne se connaissent pas forcement. Le recrutement se fait comme dans un marche. Pendant 30 minutes, dans une grande salle, chaque porteur de projets monte un espace pour présenter ses idées et inviter les gens a venir les concrétiser. C est un grand moment.

Je n ai pas de photos pour illustrer le processus. J ai trouve cette demarche d une efficacite redoutable. Je me demande si aujourd hui, une entreprise emploie ce type de technique pour les projets innovants. Si vous avez des infos la dessus, je suis preneur.

A l'issue des ces 2 jours, tous les projets sont présentés au cours d'un pitch de 3 minutes. L'équipe présente ses réalisations du week-end mais aussi le potentiel pour l'usager. Un jury de professionnels aura 10 minutes de questions / reponses pour eprouver votre concept.

Dans ce temps très court, vous pouvez présenter divers éléments comme :
- des cas d'usage
- des maquettes
- un prototype d'application
- un business model
- ...

2 jours inattendus

J'aimerai vous faire partager le déroulement complet de ces 2 jours. C est impossible, il y a bien trop à dire.

Je vous assure, c'est très intense. Vous disposez de 30 heures pour tout mettre en place. C'est un exercice particulier qui force à penser en dehors des lignes directrices que vous auriez l'habitude de suivre. Je ressors de cette expérience avec une vision beaucoup plus claire de ce qui permet de construire la vrai valeur d'un projet.

A ma grande surprise, 4 personnes m'ont rejoint pour réaliser un projet que j'avais en tête. Nous souhaitions offrir aux habitants de la région PACA et aux touristes une application qui leur donne en quelques secondes des informations sur les plages de la région comme :

  • La liste des plages les plus proches
  • La fréquentation en temps réel
  • Une carte interactive présentant toutes les plages
  • Les activités à réaliser sur les plages
  • ...

La liste est longue. C'est la magie de cet exercice. Ce que je voyais à l'origine comme une application basique est devenue, grâce aux apports de Jean Marie, Marc, Martine et Stephane, une véritable plate forme autour d'un espace de vie, la plage. J'étais le premier surpris, vu où notre réflexion nous avait mené, qu'une telle application n'existe pas.

Vamos à la playa est né :

Logo de Vamos à la playa

Nous avions la pression, le jury est venu nous annoncer que le gagnant repartirait avec un financement de 2 millions d'euros ...

Oui, nous étions tous de grands gamins bien naïfs :) . Tous les ans, je ferme les yeux pendant que le père noël vient déposer mes cadeaux ;) .

Comment atteindre l'objectif que nous nous etions fixe ?

Avoir une idée, c'est bien mais comment lui donner un sens ? Qu'est ce qui nous permettra d'arriver à un résultat ? De passer d'une simple idée à une application que les gens auraient plaisir à utiliser ? C'est ces questions que j'avais en tête durant ces 2 jours.

J'étais assez mal à l'aise vu que l'idée originale venait de moi, je ne voulais pas avoir fait perdre du temps aux personnes qui m'ont rejoint. Je désirai au fond de moi que nous aboutissions au bout de ces 2 jours à un résultat exploitable.

La première chose que nous avons faites, c'est nous forger une vision commune non pas de l'application mais plutôt des besoins auquel nous voulions amener une réponse. Ça a été l'occasion pour vraiment nous découvrir. Voir nos attentes et compétences respectives. J'ai été étonné, ce processus c'est réalisé naturellement.

Marc, qui a l'expérience du développement d'application mobile, a naturellement mené les discussions.

Un equipe heterogène

Durant ces 2 jours, j'ai été entouré de personnes exceptionnelles.

Jean Marie est le président de l'association Gullivar. Il est également contributeur pour le projet Open Street Map. Stephane est délégué régional de l'association Arsenic PACA. Martine est présidente de l'associaton Arborescence qui s'occupe d'un des Espaces Régionaux Numérique Citoyen. Marc est architecte RIA Flash dans un collectif d'indépendants Dozrock.

Jean Marie, Martine et Stephane ont fait un travail monstrueux sur la création du cahier des charges et mene la réflexion sur le business model.

(De Gauche à droite) Jean Marie, Martine et Stephane

Marc et moi avons travaillé sur le prototype d'application.

(De gauche à droite) Marc & Moi (Fabien)

Un marathon se court dans la duree

Si vous avez déjà couru un marathon, vous devez savoir que vous courez contre la distance. 30 heures, c'est court. Vous courrez contre ce chrono infernal. Ca laisse peu de place à l'incertitude.

L'incertitude, c'est comme une drogue au sein d'une equipe. Au début du projet, c est plus facile de penser que tout est maitrise par chacun. Nous pensons que tout va bien, tout le monde est génial. On préfère se dire, on avance et pour des centaines de petits points de détails nous verrons plus tard. Une difficulté se présente, nous la résolvons sans trop nous poser de questions. Sans imaginer que les autres auraient des solutions peut etre plus pertinente. On prend des décisions sur le fil, apres tout nous sommes compétents. L'exces de confiance est aussi dangereux que le manque de confiance. Au fur et à mesure que la deadline approche, le voile se lève sur l'état réel des choses. La direction prit par chacun est differente, plus rien ne fonctionne ensemble. Le retour a la realite est difficile.

Pour éviter cet effet, que l'on appelle couramment l'effet tunnel, nous avons adopté un mode de travail s'inspirant des méthodes agiles.

Sur un des panneaux nous avons écrit 5 valeurs que nous partagions.

  • Communication
  • Simplicité
  • Feed-back
  • Courage
  • Respect

Toutes les heures nous faisions un point et mettions à jour la timeline de notre projet. En permanence, nous vérifions si ce que nous préparions avait un sens par rapport aux livrables que nous avions prévu mais aussi par rapport à la vision de chacun de nous. Nous nous forcions à présenter ce qui avait été réalisé. Hors de question de se contenter seulement des paroles, nous démontrions par une demonstration ce qui avait été fait.

Si il y avait un point de blocage, meme technique, nous posions le probleme ensemble et verifions que la solution choisie allait dans le sens de tous. Elle pouvait entrainer des changements et dans ce cas, nous les realisions immediatement.

Notre source d'inspiration avec des iterations d'1h

Pourquoi fonctionner ainsi ?

Nous nous voulions pas de place pour l'incertitude. Nous pouvions prendre des risques mais nous devions en permanence vérifier que nous ne nous enfermions pas dans une réflexion qui ne mènerait nulle part. 30 heures c'est peu. Il faut parfois faire des choix difficiles et surtout les faire le plus tôt possible.

Nous avons tous joué le jeu. Je pense que ça nous a sauvé de quelques déboires.

Par exemple, Marc a rencontré des soucis pour réaliser l'application Android. N'etant pas sur sa machine de travail, il a rencontré des soucis avec son squelette. Quand nous avons constaté ça, j'ai travaillé sur une version web de la carte des plages.

Plutôt qu'importer une librairie pour utiliser Open Street Map, Marc a importé la page directement dans un canvas web. Nous avions au moins un démonstrateur pour le pitch final.

Echec ou Succes

Nous avons livré dans les temps. A dimanche 16h, à ma grande surprise, nous avions un démonstrateur et une présentation assez convaincante.

Imaginez que samedi à 10h, rien de tout ça n'existait. Ce n'etait qu'une idée fugace qui aurait pu jamais se concrétiser. 30h plus tard, c'est devenu une vrai réalisation portée par une équipe soudée par ces 2 jours incroyables.

Présentation en Tong, Short de bain et Serviettes

Je vous laisse decider a la vue de ce billet, si selon vous c'est un echec ou un succes.

Un grand merci à l'organisation

Je ne pouvais terminer ce billet sans parler du travail extraordinaire qu'a effectué l'organisation durant ces 2 jours. Nous étions dans une situation idyllique pour travailler. Nous disposions chacun d'une salle avec des posts its géant pour exprimer nos idées sur les murs.

Vous ne voyez que la face émergée de l'iceberg

Des experts étaient présents pour nous challenger et nous pousser encore plus loin dans notre réflexion. Merci à Frédéric Charles, à Marie Laure Vie, à Philippe Meddas, à Charles Nepote et encore bien d'autres dont j'ai fait l'erreur de ne pas noter les noms.

(A droite) Marie Laure et Frederic, 2 des experts Open Data

Que ce soit sur la gestion du projet, sur l'aspect business, sur l'aspect technique, nous avons à tout moment pu compter sur eux. J'ai énormément appris avec chacun de vous donc vraiment merci.

Ils ont crée un contexte idéal pour l'expression de la créativité. J'ai jamais vu autant de projets avec ce niveau de qualité présenté après seulement 30h de travail, preuve de l'excellence de l'organisation.

Frederic a écrit un billet Peux t'on penser la DSI comme un hackathon. Il nous a fait l'honneur de prendre le projet Vamos à la playa comme cas d'etude. Je vous encourage a aller le lire !

Pour conclure

Pour beaucoup, s'enfermer un week-end entier pour créer un projet avec des inconnus relève de la folie. J'aimerai leur repondre, c'est surement le cas mais la folie, c est ce qui nous a toujours fait avancer ! Ppasser un week-end avec des gens aussi exceptionnelles dans un environnement où l'on baigne dans cette énergie collective, dans un lieu où pratiquement rien ne parait impossible, ça n'a pas de prix.

Félicitation au projet Open Street Score qui a remporté ce hackathon. Votre réalisation, réalisé en si peu de temps, me laisse simplement rêveur.

Nous sortirons l'application Vamos à la playa sur IPhone et Android dans quelques semaines !

En savoir plus

Quelques adresses pour en savoir plus sur notre projet et sur le Hack Data PACA.

Voici quelques unes des réalisations de ce week-end que nous avons mis en ligne :

Remplis sous: Non classé Aucun commentaire