Est-il possible de faire l'équivalent d'une soumission de fichier par
formulaire tout en se passant de formulaire ?
Je veux pouvoir positionner $_FILES["nom du champ"] (name, error,
tmp_name) et utiliser move_uploaded_file comme s'il y avait réellement
eu une soumission.
C'est pour faire des tests unitaires d'une fonction de réception.
J'utilise actuellement PHPUnit 1.0.1 contenu dans PEAR.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Gallet
Bonjour,
Est-il possible de faire l'équivalent d'une soumission de fichier par formulaire tout en se passant de formulaire ?
Oui. Et il est bon de le rappeler : n'importe qui peut envoyer n'importe quoi à nos scripts le nombre de fois qu'il voudra à la seconde et nous ne pouvons RIEN faire pour l'en empêcher.
Je veux pouvoir positionner $_FILES["nom du champ"] (name, error, tmp_name) et utiliser move_uploaded_file comme s'il y avait réellement eu une soumission.
On est bien d'accord : je pars du principe que tu veux écrire un programme en PHP (ligne de commande probablement, sera plus simple) qui simulera une activité d'internaute et stimulera un site. Que ledit site soit écrit en PHP ou en cobol objet, on s'en tape dans le cas général, et presque aussi dans le cas précis des uploads de fichier modulo le fameux max_file_size qui est semblerait-il purement un mécanisme php.
La librairie CURL dispose de toutes les options possibles et imaginables : http://fr2.php.net/manual/en/function.curl-setopt.php
A noter que pour du GET, autant utiliser wget par exemple, c'est 'achement plus simple.
HTH JG
Bonjour,
Est-il possible de faire l'équivalent d'une soumission de fichier par
formulaire tout en se passant de formulaire ?
Oui. Et il est bon de le rappeler : n'importe qui peut envoyer n'importe
quoi à nos scripts le nombre de fois qu'il voudra à la seconde et nous
ne pouvons RIEN faire pour l'en empêcher.
Je veux pouvoir positionner $_FILES["nom du champ"] (name, error,
tmp_name) et utiliser move_uploaded_file comme s'il y avait réellement
eu une soumission.
On est bien d'accord : je pars du principe que tu veux écrire un
programme en PHP (ligne de commande probablement, sera plus simple) qui
simulera une activité d'internaute et stimulera un site. Que ledit site
soit écrit en PHP ou en cobol objet, on s'en tape dans le cas général,
et presque aussi dans le cas précis des uploads de fichier modulo le
fameux max_file_size qui est semblerait-il purement un mécanisme php.
La librairie CURL dispose de toutes les options possibles et imaginables
: http://fr2.php.net/manual/en/function.curl-setopt.php
A noter que pour du GET, autant utiliser wget par exemple, c'est
'achement plus simple.
Est-il possible de faire l'équivalent d'une soumission de fichier par formulaire tout en se passant de formulaire ?
Oui. Et il est bon de le rappeler : n'importe qui peut envoyer n'importe quoi à nos scripts le nombre de fois qu'il voudra à la seconde et nous ne pouvons RIEN faire pour l'en empêcher.
Je veux pouvoir positionner $_FILES["nom du champ"] (name, error, tmp_name) et utiliser move_uploaded_file comme s'il y avait réellement eu une soumission.
On est bien d'accord : je pars du principe que tu veux écrire un programme en PHP (ligne de commande probablement, sera plus simple) qui simulera une activité d'internaute et stimulera un site. Que ledit site soit écrit en PHP ou en cobol objet, on s'en tape dans le cas général, et presque aussi dans le cas précis des uploads de fichier modulo le fameux max_file_size qui est semblerait-il purement un mécanisme php.
La librairie CURL dispose de toutes les options possibles et imaginables : http://fr2.php.net/manual/en/function.curl-setopt.php
A noter que pour du GET, autant utiliser wget par exemple, c'est 'achement plus simple.
HTH JG
Unit Tester
Bonjour,
Merci pour ta réponse dont le contenu est intéressant, John.
Malheureusement, il semble que je me sois mal fait comprendre.
Je fais des tests unitaires pour mes développements PHP. Si personne d'autre que moi n'en fait ici, il est probable que je ne puisse pas obtenir de réponse à ma question.
J'essaie quand même d'expliciter davantage au cas où. Quand on fait des tests unitaires avec PHPUnit (disponible dans PEAR), on crée des fonctions dans une classe de tests unitaires. En dehors de fonctions obligatoires ou facultatives que j'omets volontairement, chaque fonction de test unitaire contient au moins un positionnement d'environnement prélable à un appel, un appel de fonction et une vérification de l'environnement après l'appel. Quand on fait tourner les tests unitaires, ils fonctionnent sans intervention extérieure.
Je cherche donc a positionner mon environnement de manière équivalente à une soumission de formulaire afin de faire mes tests. Je cherche aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui pourraient se produire lors de move_uploaded_file.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas adaptée à ma demande et que vous pourrez me répondre sur la faisabilité de ce que je cherche à faire.
Pour faire des tests équivalents à ce que ferait un utilisateur, je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST programmé en PHP. S'il y a un équivalent de HttpUnit en PHP, je suis quand même preneur pour des raisons d'homogeneité de langage. Maintenant, ce serait plutôt des tests de recette que des tests unitaires.
J'espère que ce texte est assez long pour être explicite et assez court pour être lu jusqu'au bout.
Cordialement,
Bonjour,
Merci pour ta réponse dont le contenu est intéressant, John.
Malheureusement, il semble que je me sois mal fait comprendre.
Je fais des tests unitaires pour mes développements PHP.
Si personne d'autre que moi n'en fait ici, il est probable
que je ne puisse pas obtenir de réponse à ma question.
J'essaie quand même d'expliciter davantage au cas où.
Quand on fait des tests unitaires avec PHPUnit (disponible dans PEAR),
on crée des fonctions dans une classe de tests unitaires. En dehors
de fonctions obligatoires ou facultatives que j'omets volontairement,
chaque fonction de test unitaire contient au moins un positionnement
d'environnement prélable à un appel, un appel de fonction et
une vérification de l'environnement après l'appel. Quand on fait
tourner les tests unitaires, ils fonctionnent sans intervention
extérieure.
Je cherche donc a positionner mon environnement de manière équivalente
à une soumission de formulaire afin de faire mes tests. Je cherche
aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui
pourraient se produire lors de move_uploaded_file.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas
adaptée à ma demande et que vous pourrez me répondre sur la faisabilité
de ce que je cherche à faire.
Pour faire des tests équivalents à ce que ferait un utilisateur,
je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST
programmé en PHP. S'il y a un équivalent de HttpUnit en PHP,
je suis quand même preneur pour des raisons d'homogeneité de langage.
Maintenant, ce serait plutôt des tests de recette que des tests
unitaires.
J'espère que ce texte est assez long pour être explicite et assez court
pour être lu jusqu'au bout.
Merci pour ta réponse dont le contenu est intéressant, John.
Malheureusement, il semble que je me sois mal fait comprendre.
Je fais des tests unitaires pour mes développements PHP. Si personne d'autre que moi n'en fait ici, il est probable que je ne puisse pas obtenir de réponse à ma question.
J'essaie quand même d'expliciter davantage au cas où. Quand on fait des tests unitaires avec PHPUnit (disponible dans PEAR), on crée des fonctions dans une classe de tests unitaires. En dehors de fonctions obligatoires ou facultatives que j'omets volontairement, chaque fonction de test unitaire contient au moins un positionnement d'environnement prélable à un appel, un appel de fonction et une vérification de l'environnement après l'appel. Quand on fait tourner les tests unitaires, ils fonctionnent sans intervention extérieure.
Je cherche donc a positionner mon environnement de manière équivalente à une soumission de formulaire afin de faire mes tests. Je cherche aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui pourraient se produire lors de move_uploaded_file.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas adaptée à ma demande et que vous pourrez me répondre sur la faisabilité de ce que je cherche à faire.
Pour faire des tests équivalents à ce que ferait un utilisateur, je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST programmé en PHP. S'il y a un équivalent de HttpUnit en PHP, je suis quand même preneur pour des raisons d'homogeneité de langage. Maintenant, ce serait plutôt des tests de recette que des tests unitaires.
J'espère que ce texte est assez long pour être explicite et assez court pour être lu jusqu'au bout.
Cordialement,
John Gallet
Re,
Je fais des tests unitaires pour mes développements PHP. Si personne d'autre que moi n'en fait ici, il est probable que je ne puisse pas obtenir de réponse à ma question.
Je teste toutes mes fonctions. Unitairment, en intégration, et en recette fonctionnelle. Mais je considère qu'il en est des tests comme de la mémoire RAM par rapport au swap et je citerai :"Memory is like orgasms, it's better not faked". Je préfère être dans des situations les plus proches possibles de la réalité (autant que faire se peut).
Quand on fait tourner les tests unitaires, ils fonctionnent sans intervention extérieure.
Ok, c'est ça l'information qui me manquait.
Je cherche donc a positionner mon environnement de manière équivalente à une soumission de formulaire afin de faire mes tests. $_FILE et/ou $_REQUEST sont des variables modifiables à volonté. Tu peux
parfaitement faire $_FILES['toto']['name']='coincoin.jpg' dans cette phase d'init. Ca, c'est facile. En revanche, je ne saurais que trop conseiller de faire un print_r( ) sur toutes les variables "superglobales" serveur avec un véritable upload pour être sûr de ne pas en oublier.
Je cherche aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui pourraient se produire lors de move_uploaded_file.
Là j'ai plus de mal à voir comment les provoquer sauf à aller modifier le code du binaire PHP pour forcer a valeur de retour. On peut facilement générer des erreurs de droits d'accès au filesystem local, mais on est quand même assez limités.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas adaptée à ma demande
J'ai l'impression : le but n'est pas d'utiliser un programme externe pour stimuler le code à tester (méthode discutable, mais soit) mais de mettre artificiellement un environnement mémoire qui (on espère...) est équivalent.
et que vous pourrez me répondre sur la faisabilité de ce que je cherche à faire.
Pour toutes les variables PHP mises en jeu, c'est facile, on peut les tripoter comme on veut. Pour le code retour des fonctions, ça mérite réflexion, là à froid je ne vois que la modification "hard" et recompilation.
Autre piste : vérifier du côté des tests de l'équipe QA de PHP http://qa.php.net/ peut-être ont-ils des "astuces" dans la test-suite.
Pour faire des tests équivalents à ce que ferait un utilisateur, je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST programmé en PHP.
Ok, je n'avais pas compris ça dans ce sens là.
S'il y a un équivalent de HttpUnit en PHP, je suis quand même preneur pour des raisons d'homogeneité de langage. Pas à ma connaissance, mais elle est assez limitée dans le domaine.
Maintenant, ce serait plutôt des tests de recette que des tests unitaires. <troll on>
Vaste débat :-)) Mais où placer les tests d'intégration dans ce cas ? ;-) <troll off>
J'espère que ce texte est assez long pour être explicite et assez court pour être lu jusqu'au bout. Par moi, oui, sans problèmes.
HTH
JG
Re,
Je fais des tests unitaires pour mes développements PHP.
Si personne d'autre que moi n'en fait ici, il est probable
que je ne puisse pas obtenir de réponse à ma question.
Je teste toutes mes fonctions. Unitairment, en intégration, et en recette
fonctionnelle. Mais je considère qu'il en est des tests comme de la mémoire
RAM par rapport au swap et je citerai :"Memory is like orgasms, it's better
not faked". Je préfère être dans des situations les plus proches possibles
de la réalité (autant que faire se peut).
Quand on fait
tourner les tests unitaires, ils fonctionnent sans intervention
extérieure.
Ok, c'est ça l'information qui me manquait.
Je cherche donc a positionner mon environnement de manière équivalente
à une soumission de formulaire afin de faire mes tests.
$_FILE et/ou $_REQUEST sont des variables modifiables à volonté. Tu peux
parfaitement faire $_FILES['toto']['name']='coincoin.jpg' dans cette phase
d'init. Ca, c'est facile. En revanche, je ne saurais que trop conseiller de
faire un print_r( ) sur toutes les variables "superglobales" serveur avec un
véritable upload pour être sûr de ne pas en oublier.
Je cherche
aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui
pourraient se produire lors de move_uploaded_file.
Là j'ai plus de mal à voir comment les provoquer sauf à aller modifier le
code du binaire PHP pour forcer a valeur de retour. On peut facilement
générer des erreurs de droits d'accès au filesystem local, mais on est quand
même assez limités.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas
adaptée à ma demande
J'ai l'impression : le but n'est pas d'utiliser un programme externe pour
stimuler le code à tester (méthode discutable, mais soit) mais de mettre
artificiellement un environnement mémoire qui (on espère...) est équivalent.
et que vous pourrez me répondre sur la faisabilité
de ce que je cherche à faire.
Pour toutes les variables PHP mises en jeu, c'est facile, on peut les
tripoter comme on veut. Pour le code retour des fonctions, ça mérite
réflexion, là à froid je ne vois que la modification "hard" et
recompilation.
Autre piste : vérifier du côté des tests de l'équipe QA de PHP
http://qa.php.net/ peut-être ont-ils des "astuces" dans la test-suite.
Pour faire des tests équivalents à ce que ferait un utilisateur,
je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST
programmé en PHP.
Ok, je n'avais pas compris ça dans ce sens là.
S'il y a un équivalent de HttpUnit en PHP,
je suis quand même preneur pour des raisons d'homogeneité de langage.
Pas à ma connaissance, mais elle est assez limitée dans le domaine.
Maintenant, ce serait plutôt des tests de recette que des tests
unitaires.
<troll on>
Vaste débat :-)) Mais où placer les tests d'intégration dans ce cas ? ;-)
<troll off>
J'espère que ce texte est assez long pour être explicite et assez court
pour être lu jusqu'au bout.
Par moi, oui, sans problèmes.
Je fais des tests unitaires pour mes développements PHP. Si personne d'autre que moi n'en fait ici, il est probable que je ne puisse pas obtenir de réponse à ma question.
Je teste toutes mes fonctions. Unitairment, en intégration, et en recette fonctionnelle. Mais je considère qu'il en est des tests comme de la mémoire RAM par rapport au swap et je citerai :"Memory is like orgasms, it's better not faked". Je préfère être dans des situations les plus proches possibles de la réalité (autant que faire se peut).
Quand on fait tourner les tests unitaires, ils fonctionnent sans intervention extérieure.
Ok, c'est ça l'information qui me manquait.
Je cherche donc a positionner mon environnement de manière équivalente à une soumission de formulaire afin de faire mes tests. $_FILE et/ou $_REQUEST sont des variables modifiables à volonté. Tu peux
parfaitement faire $_FILES['toto']['name']='coincoin.jpg' dans cette phase d'init. Ca, c'est facile. En revanche, je ne saurais que trop conseiller de faire un print_r( ) sur toutes les variables "superglobales" serveur avec un véritable upload pour être sûr de ne pas en oublier.
Je cherche aussi a pouvoir reproduire tous les types d'erreur d'upload ou qui pourraient se produire lors de move_uploaded_file.
Là j'ai plus de mal à voir comment les provoquer sauf à aller modifier le code du binaire PHP pour forcer a valeur de retour. On peut facilement générer des erreurs de droits d'accès au filesystem local, mais on est quand même assez limités.
J'espère que vous aurez saisi en quoi la solution proposée n'est pas adaptée à ma demande
J'ai l'impression : le but n'est pas d'utiliser un programme externe pour stimuler le code à tester (méthode discutable, mais soit) mais de mettre artificiellement un environnement mémoire qui (on espère...) est équivalent.
et que vous pourrez me répondre sur la faisabilité de ce que je cherche à faire.
Pour toutes les variables PHP mises en jeu, c'est facile, on peut les tripoter comme on veut. Pour le code retour des fonctions, ça mérite réflexion, là à froid je ne vois que la modification "hard" et recompilation.
Autre piste : vérifier du côté des tests de l'équipe QA de PHP http://qa.php.net/ peut-être ont-ils des "astuces" dans la test-suite.
Pour faire des tests équivalents à ce que ferait un utilisateur, je dispose de HttpUnit ou HtmlUnit en Java plutôt que de faire un POST programmé en PHP.
Ok, je n'avais pas compris ça dans ce sens là.
S'il y a un équivalent de HttpUnit en PHP, je suis quand même preneur pour des raisons d'homogeneité de langage. Pas à ma connaissance, mais elle est assez limitée dans le domaine.
Maintenant, ce serait plutôt des tests de recette que des tests unitaires. <troll on>
Vaste débat :-)) Mais où placer les tests d'intégration dans ce cas ? ;-) <troll off>
J'espère que ce texte est assez long pour être explicite et assez court pour être lu jusqu'au bout. Par moi, oui, sans problèmes.