Discussion :

[koven]

Bonjour à tous,

pour une application MVC je suis en train de rédiger des tests unitaires. La question est plus de l'ordre du bon sens qu'autre chose.

Il s'agit de tester une fonction de mon modèle qui ajoute un membre dans ma base de données. J'utilise un Framework qui met par défaut les valeurs vides des variables ($_POST) à 0. Côté mysql, les valeurs 0 n'étant pas considérées comme NULL, la contrainte NOT NULL sur ma colonne ne peut être appliquée (Email dans mon cas).

Dans mon contrôleur, je vérifie que la variable $_POST['email'] n'est pas vide et que c'est un email valide. Ce qui signifie que l'email doit obligatoirement être sous la forme x@y.z. Je fais ceci avant d'appeler la fonction d'ajout de membre de mon modèle.

Ma question est donc, est-ce que j'ai besoin de tester une valeur $_POST['email'] = '' dans mon modèle ?

Merci pour vos réponses, ça prend la tête ces tests !

[Gruik]

Hello

Donc c'est une question sur la bonne implémentation du principe MVC.

Au premier abord je dirais que ce doit être fait au niveau modèle, donc enlevé du contrôleur et mis dans le modèle dans le check avant sauvegarde (création ou màj).
Si on fait ça, se pose la question de comment transmettre le résultat du check ; certains optent pour retourner une liste de messages d'erreur à retransmettre à l'utilisateur (ou lever une exception dont le message associé est à transmettre à l'utilisateur) mais je suis pas trop pour ça. Je préfère retourner un code d'erreur (numérique via constante ou alphanumérique) ou une liste de codes d'erreur (ou lever une exception contenant le code d'erreur) et ensuite associer à tel code d'erreur tel message dans le contrôleur (ou faire tout autre traitement).

Après ce n'est pas une obligation, ça dépend de si on estime que dans tous les cas ces checks doivent avoir lieu avant de créer/màj ces entités ou non, et pour ça faut imaginer d'autres cas où on utilise les modèles (ailleurs que via ce controleur) en creation/màj. Il y aurait peut être d'autres pages dédiées à d'autres types d'utilisateur où les checks seraient moindres (auquel cas il faut enlever des checks du modèle pour ne garder que le dénominateur commun), et sinon toujours penser aux cas où on utilise le modèle dans un traitement d'un autre modèle ou dans un processus non web (appel en ligne de commande / cron).