Le modèle MVC

Le fameux Modèle Vue Controlleur. Si vous vous dites qu’à part avec un test fonctionnel (c’est à dire un test qui simule le comportement utilisateur via des clicks, avec un sfBrowser ou Selenium) ça va pas être possible de tester votre appli, c’est surement vrai ; que les tests fonctionnels ça se fait vers la fin de l’écriture de votre module, quand votre code HTML bouge plus trop c’est vrai aussi ; et que donc dans le coup vous voyez pas trop comment tester votre application avant de l’avoir finie, c’est vrai aussi.

Du M dans le C

Mais si vous vous dites tout ça, c’est qu’il y a du M dans le C. C’est à dire qu’il y a des parties de votre Modèle dans votre Controlleur et dans le coup, vous ne pouvez tester votre modèle sans votre Controlleur (et dans le coup sans la Vue aussi). C’est typiquement le cas quand vous faites quelque chose comme ça :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$titi)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Faites pas style c’est pas vous, je vous ai vu. Pourquoi ne pas faire ça dans l’action :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->getObjectsByTiti($titi);
  }

et ça dans la classe ObjectTable :

  public function getObjectsByTiti($titi)
  {
	return Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$toto)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Vous serez d’accord avec moi que le résultat est le même mais que c’est un peu plus découplé. On pourra reparler plus tard du fait que le summum serait de retourner un tableau (le fameux HYDRATE_ARRAY de Doctrine passé à la requête) dans la méthode getObjectsByTiti afin de ne pas se retrouver avec quelque chose dépendant de dépendant de l’ORM dans le controlleur (ici une Doctrine_Collection), mais ce n’est pas le sujet ici ;-)

Si c’est pareil, pourquoi c’est mieux alors ?

Parce que je vous le dis ! Oui bon d’accord. Plusieurs avantages, vous n’avez qu’un endroit à aller voir en cas de souci de logique métier : le Modèle. Mais surtout plus vous en mettrez dans le modèle (le premier que je vois écrire du HTML dans le modèle devra coder avec Wordpad), plus vous pourrez en tester ! Et plus vous écrirez de tests unitaires pour vos modèles, plus vous serez confiant dans votre code et plus votre code sera de qualité. Vos controlleurs devraient faire environ 10 lines de code, pas plus. Essayez de vous y tenir, ça vous changera la vie (mettez ce qui concerne la sessions dans votre classe myUser par exemple).

Maintenant nous pourrions écrire un test unitaire du style :

$t->ok(
  count(Doctrine::getTable('Object')->getObjectsByTiti('mogito'))>4,
  '-> Getting object by mogito returns more than 4 objects');

Ici je teste que notre méthode retourne au moins 4 objets si je lui demande un mogito.

Vers la rédemption

Si vous faites bien attention de ne pas avoir de M dans le C, vous pourrez coder toute votre logique applicative sans ouvrir un seul navigateur internet, et c’est même ce que vous devrez vous forcer à faire. Vous pouvez, voire même devez, faire marcher votre logique métier sans la moindre page web, juste en faisant tourner vos tests unitaires qui sont suffisants (et nécessaires) pour voir si votre code est bon et fait ce qu’il doit faire.

En faisant ça, vous pourrez ne vous concentrer que sur le modèle, sur le coeur de la logique métier, sans être parasité par des besoins webs (que le formulaire soit valide pour pouvoir récupérer l’objet, c’est pas le problème du modèle ça !).

Une fois que vous aurez les principales fonctions métier de codées dans votre modèle vous pourrez ensuite écrire vos controlleurs et pages web et à la fin les tests fonctionnels. Mais avant de faire ça, vous saurez qu’il y aura déjà une bonne partie de votre code qui sera écrit et testé.

Et après ?

Quand vous aurez pris l’habitude d’écrire des tests unitaires et que vous en serez devenu accrocs, vous pourrez passer au développement guidé par les tests (le TDD). Là vous écrivez avant les tests (donc en gros ce que vous attendez de votre modèle) et ensuite vous écrivez le modèle : vous serez assuré que tout votre modèle est couvert par les tests, et vous aurez écrit ce que doit faire votre modèle avant de l’avoir implémenté (c’est toujours bien de réfléchir avant de coder, sisi).

Quand vos tests commencerons à prendre du temps à s’exécuter, vous commencerez à vous intéresser à des outils d’intégration continue comme phpUnderControl ou Hudson, dont NiKo a récemment décrit l’intégration avec symfony dans un de ses articles.

Pour finir, en effet ça va vous demander plus de temps de réaliser votre application web en écrivant des tests unitaires. Comme vous êtes Freelance et que le temps c’est de l’argent, vous vous dites que vous ne le ferez pas. Oui mais quand vous aurez livré et que le client reviendra 10 fois vers vous ensuite à cause de bugs, ou que vous aurez changé quelque chose qui aura tout cassé sans que vous ne vous en rendiez compte, et que ça commencera à se savoir que ce que vous faites est buggé : vous penserez fortement à une méthode qui vous permettra d’être beaucoup plus confiant dans votre code, à savoir l’écriture de tests !

Si vous êtes stagiaire ça marche aussi pour prendre de bonnes habitudes et ne pas vous faire taper dessus par votre supérieur, si vous êtes salarié reportez vous au cas du stagiaire ;-)