+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) (/showthread.php?tid=3765)
Pages :
1
2
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - keke - 06-03-2009
Ebe > Ce à quoi l'XP répondrait qu'un bon code ne contient aucun commentaire. Les noms des variables, la manière de coder devant se suffire à elle même pour la compréhension.
Pour ma part, le ratio commentaire/code est grosso-modo d' 1/4.
Un algo => un commentaire
Un include => un commentaire si besoin
Un appel à une fonction avec des paramétres étranges => un commentaire
Kéké
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - pascal - 06-03-2009
Pour les commentaires, je rejoint keke, mais avec encore moins de commentaires. L'architecture générale doit être documentée, ensuite en suivant les conventions, il n'y a pas grand chose à expliquer, sauf peut être des trucs un peu compliqués ou un peu abstraits.
Une lecture intéressante sur les commentaires :
http://blog.developpez.com/bruno-orsier/p7221/bonnes-pratiques/programmation/les-commentaires-traduisent-notre-echec-/
Pour en revenir au debuggage, ce que j'expose est vraiment basique de chez basique. Le "vrai" débuggage commence au point 3, voire après.
Un bug n'est pas forcément une erreur avec un message.
Quasiment tous les bugs de ce genre (avec message) sont pour moi des "erreurs de codage", elles doivent être évitées avant d'en arriver au 3.
Un bug est un truc comme :
- aucun message d'erreur
- tout semble se passer normalement (ou presque)
- et on n'a pas le comportement voulu, si on regarde de plus près
C'est plutôt :
- j'appuie sur attaquer, mais l'attaque n'a pas lieu
- l'attaque a lieu, mais sur une cible différente de celle que je veux attaquer
- lorsque j'arrive à 0 point d'action, je peux encore faire des actions (effet de bord ?)
Pour faire une comparaison avec la langue française :
- un message d'erreur = une faute d'orthographe, de conjugaison, d'accord dans un texte
- pas de message d'erreur = on a un texte qui passe le correcteur orthographique, mais il contient des phrases qui ne veulent rien dire
Les tests unitaires sont une manière de vérifier le sens que prend le code, en plus de vérifier que l'orthographe est respectée.
A+
Pascal
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - keke - 06-03-2009
Ha ben tiens. J'entends beaucoup parler de test unitaire (surtout après l'exposé sur le Xtrem Programming).
Comment t'y prends-tu pour faire tes tests unitaires ? (tu peux prendre un exemple précis qu'on pourra généraliser ensuite ?)
Kéké
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - Allwise - 06-03-2009
Ouais enfin, pour les commentaires je suis pas d'accord avec l'article posté par Pascal, il est selon moi trop catégorique.
Ne serait-ce que pour la description de la signature des fonctions, qui est traduite en API / documentation avec des outils comme Javadoc et phpdoc. Ce sont là des commentaires, et perso je préfère lire en quelques lignes le comportement d'une fonction plutôt que lire toute la fonction.
Malgré toute la bonne volonté que peut mettre un développeur à rendre son code explicite, il sera de toute manière limité par le langage, qui reste un langage de programmation avec ses limites. Je vois pas où est le mal à traduire des trucs complexes en des phrases plus accessibles au sein d'un code source, enfin bon... Je suppose que c'est une question qui trouve sa réponse dans l'expérience et les besoins de chacun.
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - pascal - 06-03-2009
(06-03-2009, 04:39 PM)keke a écrit : Ha ben tiens. J'entends beaucoup parler de test unitaire (surtout après l'exposé sur le Xtrem Programming).
Comment t'y prends-tu pour faire tes tests unitaires ? (tu peux prendre un exemple précis qu'on pourra généraliser ensuite ?)
humpf, je ne retrouve plus le code de mes tests (pour une boutique il y a quelques années de ça...) et je n'ai pas encore fait de tests pour creajeu (je code et je débuggue à la place, c'est pas bien, mais bon...)
alors les tests unitaires en rapide :
- on utilise une librairie pour vérifier le résultat de fonctions : valeurs, valeurs en DB, fichier créé, supprimé...
- on ne peut pas tester du code full paté, il faut des fonctions ou des classes à tester
- chaque fonction/méthode doit faire un petit bout du travail : on ne peut tester que des choses "simples" car petites
- pour tester des valeurs en base de données, il faut une base de test, dédiée à ça. ce n'est pas la base de dev que l'on utilise en codant. c'est une base qui est recréée par script à chaque lancement de test (au moins pour les valeurs en DB; on peut garder la structure des tables)
on va prendre en exemple la vérification de mail :
- il faut vérifier le modèle : dutexte@undomaine.uneextension
La fonction à coder vérifiera ce modèle et renverra TRUE ou FALSE; elle n'enregistrera rien en base de données, elle ne fera que vérifier, comme ça elle reste simple et est "unitaire" fonctionnellement.
on va se créer des données de test, dans un tableau :
$key=>$value pour entrée=>sortie :
"un mail à tester" => "TRUE ou FALSE en retour"
Code PHP :
<?php
$mailList = array(
'ceci nest pas un mail' => FALSE,
'toto@test.com' => TRUE,
'toto@.com'=>FALSE,
''=>FALSE,
'@'=>FALSE
);
Créer cette liste donne des idées :
- il faut tester des adresses valides, bien sûr
- il faut tester des trucs qui n'ont rien à voir
- ne pas oublier ce qui ressemble vaguement au mail
- et le mail vide ( * = c'est une valeur effet de bord, à ne pas oublier)
Le test unitaire va ressembler à ça :
Code PHP :
<?php
// donnees de test
$mailList = array(
'ceci nest pas un mail' => FALSE,
'toto@test.com' => TRUE,
'toto@.com'=>FALSE,
''=>FALSE,
'@'=>FALSE
);
// test de la fonction
foreach($mailList AS $mail => $output)
{
assertEqual( verifMail($mail), $output);
}
Avec la fonction assertEqual qui vérifie que les valeurs soumises sont égales. En cas de différence, une erreur est indiquée ( c'est une version simplifiée de simpletest : http://onpk.net/php/simpletest/index.php )
Là on a écrit le test, mais pas encore la fonction à tester. Mais on a déjà des avantages :
- on sait quels cas on doit traiter, car on les a sous les yeux. En regardant les liste de plus près, on peut éventuellement trouver des valeurs manquantes, et les rajouter facilement
- on en sait plus sur la signature de la fonction : en entrée un mail à vérifier, en sortie un booléen
On peut coder la fonction de vérif. de mail, ou en récupérer une sur le net et la tester.
Pratique dans le temps :
- à court terme, tout de suite, on sait si ça répond aux spécifications ( les spécifications sont les données de test
)- à long terme, on pourra faire évoluer cette fonction
Alors, des évolutions ?
on a remarqué que des bots attaquent le jeu depuis la russie, mais les USA ne peuvent rien faire pour aider. On décide d'un embargo :
on interdit les mails en *.ru
comment faire ?
- on ajoute une donnée de test :
Code PHP :
<?php
"dimitri@mir.ru"=>FALSE
- on modifie la fonction : les mails en *.ru sont invalidés
- on teste, ça marche !
- si ça ne marche pas, c'est qu'on a introduit un bug : on le voit tout de suite et on corrige, puis relance le test.
Grâce aux tests unitaires, le code évolue*
Le mail est un exemple simple, mais sur des centaines de fonctions / des dizaines de classe, ça permet de détecter des trucs plus compliqués et de faire évoluer sans régression.
A+
Pascal
* = et on a gagné la guerre froide
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - Ter Rowan - 06-03-2009
en tout cas merci Pascal, je croyais personnellement que les tests unitaires se faisaient unitairement donc .. à la main ^^
du coup, je pensais faire des tests unitaires là où je faisais de la bidouille...
erf
va falloir revoir cela
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - Zamentur - 06-03-2009
Moi je fais ces tests comme pascal.
Et effectivement je n'ai pas encore tester mon interface, notamment parce que je n'en suis pas là. Mais effectivement c'est une bonne remarque.
Pour ne pas perdre de temps, je procède ainsi:
- réflexion sur le package de fonctionnalité
- écriture des fichiers de test
- écriture des "squelettes" (classe, fonction etc...)
- remplissage des squelettes
- debugging grâce aux fichiers test
- revu de la sémantique et de la conformité du code
Bien sur il faut se rendre compte qu'on peut évidement retourner à une étape précédente si il s'avère que l'on a pas pensé à quelques choses...
Un de mes fichier test (assez archaïque):
Code PHP :
<?php
/**
* Test Unitaire du package configuration.class.php
*
* Ce fichier à pour but de tester la classe d'obtention de configuration
*
* @author LJF
* @version 1.0
* @package Debug
*/
//==============================================================================
//Initialisation
//==============================================================================
header('Content-type: text/html; charset=UTF-8');
require_once('location.php');
function result_test($title,$condition=true) {
echo '<br>'.$title.':'.(($condition)?'[ok]':'<b style="color:red">[échoué]</b>');
}
require_once(URI_ROOT.'classe/configuration.class.php');
//Création d'un fichier /conf/test.conf.php
$data='<?php
$array["ok"] =true;
return $array;';
file_put_contents (URI_ROOT.'conf/test.conf.php',$data);
//==============================================================================
//Démarrage du test
//==============================================================================
echo '<h1>Test Unitaire du packet configuration.class.php:</h1><blockquote>';
result_test('Création du gestionnaire de paramètre',($conf=configuration::get_instance()));
result_test('Test d\'unicité du gestionnaire de paramètre',($conf===configuration::get_instance()));
result_test('Récupération d\'un paramètre',$conf->test__ok===true);
echo '</blockquote>';
//==============================================================================
//Nettoyage
//==============================================================================
unlink(URI_ROOT.'conf/test.conf.php');
Le véritable contenue du test se trouve ici:
Code PHP :
<?php
result_test('Création du gestionnaire de paramètre',($conf=configuration::get_instance()));
result_test('Test d\'unicité du gestionnaire de paramètre',($conf===configuration::get_instance()));
result_test('Récupération d\'un paramètre',$conf->test__ok===true);
Ici on test un design pattern singleton ainsi qu'une surcharge de membres...
La surcharge de membres permet d'accéder à une variable contenue dans un fichier en appelant le membre "virtuel" $conf->NomFichier__NomVariable.
A noter qu'ici il n'y a pas de test au niveau des erreurs éventuels(variable inexistante, fichier de config manquant, ni de test concernant la rapidité). Alors qu'il devrait.
Concernant les évolutions on pourrait imaginer passer d'un design pattern singleton à une classe permettant une unique instances par repertoire de configuration. Ici la valeur par défaut est prise.
Ça donnerait alors:
Code PHP :
<?php
result_test('Création du gestionnaire de paramètre',($conf=configuration::get_instance()));
result_test('Test d\'unicité du gestionnaire de paramètre',($conf===configuration::get_instance()));
result_test('Récupération d\'un paramètre',$conf->test__ok===true);
result_test('Obtention d\'une autre configuration',($conf2=configuration::get_instance('/conf2/')));
result_test('Test de différence entre les 2 instances de configuration',($conf!==$conf2));
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - pascal - 06-03-2009
effectivement, les tests unitaires sont des fichiers de tests, que l'on peut relancer tant que l'on veut, via le navigateur.
pour l'interface, j'ai un peu utilisé Selenium, pratique avec le plugin firefox, car on peut enregistrer une navigation :
http://seleniumhq.org/
Dans symfony, on peut utiliser le testeur de navigation :
http://www.symfony-project.org/jobeet/1_2/Propel/en/11
Voilà,
A+
Pascal
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - Zamentur - 07-03-2009
J'ai commencé çà, n'hésitez pas à compléter, critiquer
http://wiki.jeuweb.org/tutoprog/deboguer
RE: un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois) - Hakushi - 07-03-2009
+1 pour Selenium, j'ai eu une petite demo a la conférence PHP Québec cette semaine, et c'est plutot pas mal.
Après pour les tests unitaires, PHPUnit fait vraiment bien son boulot.
Sinon d'une manière générale, suivre les standards Zend ou PEAR pour le code est un premier pas vers quelque chose de propre, documenter ses classes, activer l'error_reporting en dev (E_ALL), surveiller les E_DEPRECATED, E_NOTICE et E_STRICT.