un grand auteur a dit : "tu fais comment pour debugger ?" (en plus deux fois)

[keke]

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é

[pascal]

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/...re-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

[keke]

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é

[Allwise]

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.

[pascal]

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

); 

[Ter Rowan]

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

[Zamentur]

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'); 

[pascal]

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

[Zamentur]

J'ai commencé çà, n'hésitez pas à compléter, critiquer
http://wiki.jeuweb.org/tutoprog/deboguer

[Hakushi]

+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.