Discussion :

[Vetea]

C'est dingue ... Je comprend rienGG sur le fil de la discussion ...
Pire je suis perdu après quelques lignes de lecture et j'ai pas envie d'en lire plus !
Je suis sur que cela doit être très intéressant, mais le sujet s'adresse a des "initiés" du milieu laissant les autres n'y connaissant pas grand chose comme moi, sur le côté pour peu qu'il faille faire des recherches à chaque terme technique.

Mais bon, je te souhaite bon courage l'ami !!

[Dabou Master]

C'est dingue ... Je comprend rienGG sur le fil de la discussion ...
Pire je suis perdu après quelques lignes de lecture et j'ai pas envie d'en lire plus !

Imagine ce que je ressens depuis que je suis arrivé sur ce forum .
Mais bon on était prévenus depuis le départ, ce qui me navre c'est que je me rends compte que tout ce que j'ai pu apprendre à mon BTS (certes pas grand chose mais au moins les bases de l'algo) ne me sert strictement à rien, pire, certains trucs me paraissent tellement simples (genre ce qu'est l'orienté objet) et j'en vois avoir tellement de mal à appréhender la chose que je me dis que je n'ai tout simplement rien compris ...
Que ça te décourage pas à apprendre le C++ dans un futur proche, ne déteste pas les technologies récentes parce que ces deux vilains messieurs font peur ^^.
J'arrête d'embêter tout le monde, je disparais.

[yildiz-online]

Désolé pour cette aparté technique un peu obscure Vetea et Dabou,

pour vous faire un petit résumé des méthodes de test, voici ce qu'on peut faire:

-test unitaires: c'est un test qui va se focaliser sur une seule fonction, en prenant soin de vérifier tous les chemins possibles dans la fonction, et leur comportement.

-test d'intégration, ce sont des tests d'interactions entre divers composants du logiciel, ça peut aller de 2 classes entre elles, 2 modules,... jusqu'à 2 logiciels différents qui communiquent.

-test de non-régression: après avoir implémenté une nouvelle fonctionnalité/corrigé un bug, vérifier qu'elle fait bien ce qu'on attend d'elle (donc on teste juste la fonctionnalité)

-test de régression: après avoir implémenté une nouvelle fonctionnalité/corrigé un bug, vérifier qu'on a rien cassé autour (donc on teste les éléments impactés par le changement)

-test de comportement (behavior driven dev) une suite de tests d'intégration/non-régression qui sont définis en langage courant(français, anglais) puis traduits par le logiciels en instructions testables

il y a encore plein de chose, le testing est un vrai métier, ici on a juste couvert la partie faite par les développeurs, et c'est déjà pas mal!

[Neckara]

@Dabou Master, Vetea
Désolé pour cela. Le problème, c'est qu'on parle entre initiés de choses un peu avancé.
Le sujet de Last Escape est normalement beaucoup moins technique donc il devrait vous plaire un peu mieux ^^.

En gros, je suis en train d'écrire du code pour tester du code, vérifier que le code que j'ai (ou un autre) bien écris fait ce que je veux qu'il fasse.
Si j'ai une fonction "addition" qui prend deux entiers x et y et qui retourne un autre entier, je peux coder un test qui va appeler ma fonction avec différents paramètres et qui va vérifier son résultat.

Ce qui permet de "s'assurer" que notre fonction marche bien et qu'elle marchera toujours même si on la modifie 2 ans plus tard ou qu'on modifie un des fonctions appelée par notre fonction.


Donc là, le problème, c'est que yildiz-online me dit :
"C'est bien beau tout cela, mais ce que tu écris, ça existe déjà, pas bien de réinventer la roue".

Ce à quoi je lui répond :
"Hey, tout calme, je maîtrise
Ne compare pas ce que je fais à l'existant, mon truc est total innovant, tu peux pas test.
Et puis même si je réinvente la roue, c'est une toute petite roue pour éviter de réinventer des roues plus grandes."


===== FIN DU DISCOURS VETEA-FRIENDLY ======
Continuez à vos risques et périls.

-Changer de dépendance est relatif au niveau d'abstraction, plus il est élevé, plus le changement sera simple(mais plus l'intégration d'une nouvelle dépendance sera couteux)
-Changer de version est transparent, sauf dans le cas de version majeure, dans ce cas, il faut peser le pour et le contre et résister à la tentation de toujours vouloir être uptodate, quoi qu'il arrive, c'est contre productif.
-Un abandon ça arrive en effet, dans ce cas, suivant le niveau d'abstraction, il sera plus ou moins facile de passer à une autre lib.

Justement, les modules forcent un certain niveau d'abstraction et forcent la réduction des couplages, bref, ils forcent à programmer correctement.
Au début, on programme toujours correctement, puis plus ça va plus on va au plus rapide :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/** @brief Ma fonction
*
* Ma superbe fonction qui sert à
* @param bla
* @return
* @date
* @authors
* @copyright
*/
int taux_TVA_France_1990_categorie_a(int somme);
 
// Un mois plus tard :
int tx(int);

Donc, je pense qu'on a besoin de quelque chose pour nous contraindre à faire les choses correctement.

-Les plateforme d’exécution devraient être choisies en début de projet, et spécifiées dans le cahier des charges, vouloir une extensibilité infinie rend le code complexe et non maintenable(voir l'anti pattern YAGNI(you aint gonna need it))

YAGNI est un anti pattern ?
Mon système de module permet justement de faciliter les maintenances et ne rend pas le code complexe. De plus, c'est surtout pour les màj, les échanges de modules et permettre à chacun d'écrire son propre module que c'est très intéressant.

-Les dépendances transitives sont toujours pénibles, il faut bien les gérer pour éviter les mauvaises surprises(conflit de versions) un petit diagramme de composant fait ça très bien.

La flemme .

Tout à fait d'accord pour le coté modulaire, cependant, pour tout ce qui est cross cutting concern, c'est de la responsabilité du noyau, imagine que chacun vienne avec sa lib de test ou de log, les rapports seront dans des formats différents, des fichiers éparpillés, c'est pas gérable.

Je ne fonctionne pas tout à fait comme cela.
Si tu veux un service, tu n'utilises pas une lib externe, tu utilises un autre module qui utilise éventuellement cette lib externe.
Mais, ce module doit respecter des contraintes définies par "l'API" qu'il implémente.

Donc, ce n'est pas le noyau qui est responsable, mais les interfaces qui seront implémentées dans les modules.
Ce qui permet de pouvoir réutiliser le noyau même si on ne veut absolument pas suivre certaines contraintes, mais le tout ne sera pas considéré comme "compatible" avec le moteur.

Tu peux trouver de la doc sur l'anti pattern NIH (not invented here) qui donne un bon aperçu de tous les risques à vouloir tout refaire soi même.

Le système de module permet justement de ne pas réinventer la roue en facilitant l'utilisation propre de bibliothèques externes.
Mais le noyau doit être le plus indépendant possible sinon c'est le serpent qui se mord la queue.

Enfin bon :

• le noyau du moteur, c'est quelques dizaines de lignes ;
• le système de module c'est relativement petit et il n'existe pas de normes C++ à ce sujet. Pas sûr qu'il existe de bibliothèques matures équivalentes.
• le noyau de tests, c'est quelques centaines de lignes, mais d'un autre côté, je pense que j'invente 2-3 trucs ^^.

C'est vraiment pas énorme sachant que ce sont les seules "roues" que je réinvente.

[Invité]

Tout ce que j'ai compris dans ces discours c'est que tu essayes de faire comme moi.

Mais en utilisant des termes technique qui m'échappe complètement.

En c++ je n'ai jamais eu besoin de faire tout ces tests là, mais parfois, je me demande si tu sais vraiment ce que tu fais ou bien si tu pars un peu dans tout les sens.

Car tu te penches sur last-escape, ensuite, sur un autre projet, et puis encore un autre projet, puis sur les cours, bref, j'ai plusieurs projets aussi mais j'ai le sentiment de mieux savoir vers quoi je veux aller.

Mais bon je me trompe peut être, peut être que ton projet aboutira à quelque chose d'ici quelques années, car là, je ne vois pas l'utilité de ton idée, tu dis vouloir faire un noyaux qui chargerais plusieurs fichiers .dll ou bien .so dans des .lem si j'ai bien compris mais.

En linkage static cela est beaucoup plus rapide et c'est vachement moins la galère pour les tests, même si il faut linker beaucoup de dépendance et que toutes ne sont pas supportée, cela règle les soucis d'interdépendance.

Au départ je trouvais ton idée bonne mais là je commence à avoir quelques doutes.

Pas moyen de faire des modules de façon dynamique qui sont interdépendant, parfois je dois laisser du code dans les .h sinon le linkage foire, et, le plus simple pour coder de façon générique est de faire une librairie header only comme boost par exemple.

Et au pire faire du linkage statique pour les .cpp

Conclusion : au départ je pensais utiliser ta librairie mais comme mes fonctions ne comporte pas beaucoup de code, je pense faire, plus tard, une librairie header only.

[Neckara]

En c++ je n'ai jamais eu besoin de faire tout ces tests là, mais parfois, je me demande si tu sais vraiment ce que tu fais ou bien si tu pars un peu dans tout les sens.

Car tu te penches sur last-escape, ensuite, sur un autre projet, et puis encore un autre projet, puis sur les cours, bref, j'ai plusieurs projets aussi mais j'ai le sentiment de mieux savoir vers quoi je veux aller.

Il est vrai, que dans un premier temps je suis passé de "Last Dungeon" à "Last DunGo" à "Last Engine" à "Last Escape".
4 projets en 4 ans, c'est pas énorme.

Le premier changement de projet était nécessaire, "Last Dungeon" étant beaucoup trop ambitieux.
J'ai fini un prototype jouable de "Last DunGo", mais je voulais le réécrire plus proprement avec un moteur d'où "Last Engine".
Après, ce moteur, il faut l'écrire, le tester et l'éprouver, d'où "Last Escape".

Je n'ai donc que deux projets pour le moment : "Last Engine" et "Last Escape" que je fait évoluer en parallèle.
En effet "Last Escape" utilisant "Last Engine", bosser sur "Last Escape" revient à écrire et tester des modules pour "Last Engine".


En ce qui concerne les tests, on va dire "Last Tests" (je sais que vous enviez mon originalité pour trouver les noms), c'est un outil fournit dans "Last Engine", outil qui m'a pris 3 jours à développer. Il est d'ailleurs utile et cohérent avec ma politique de module, au lieu de donner des interfaces, je donnerais des interfaces + des tests.

Mais bon je me trompe peut être, peut être que ton projet aboutira à quelque chose d'ici quelques années

En effet, je n'ai que peu de temps libre, mais une fois la base finie, le moteur sera directement utilisable, la première version va d'ailleurs bientôt sortir.

tu dis vouloir faire un noyaux qui chargerais plusieurs fichiers .dll ou bien .so dans des .lem si j'ai bien compris

Non, les .lem sont des .dll/.so

En linkage static cela est beaucoup plus rapide et c'est vachement moins la galère pour les tests

Les modules sont des .dll/.so, il n'y a donc pas de problème à les lier statiquement.
Et si tu veux conserver le gestionnaire de modules, il te suffit de redéfinir une seule classe.

même si il faut linker beaucoup de dépendance et que toutes ne sont pas supportée, cela règle les soucis d'interdépendance.

Par contre, tu ne pourras pas changer de modules sans recompilation.

Donc tu empêches l'écriture de modules puis leurs distributions par un tiers.

Pas moyen de faire des modules de façon dynamique qui sont interdépendant

Je ne vois pas pourquoi ce ne serait pas possible.

parfois je dois laisser du code dans les .h sinon le linkage foire

Cela n'a rien à voir avec le fait d'avoir des modules de façon dynamique.

le plus simple pour coder de façon générique est de faire une librairie header only comme boost par exemple.

Ce n'est pas un problème de généricité, mais de "personnalisation" et de "segmentation" des différents modules.
De plus ne confond pas, la généricité est dû aux templates, pas au fait que ce soit header-only.

Conclusion : au départ je pensais utiliser ta librairie mais comme mes fonctions ne comporte pas beaucoup de code, je pense faire, plus tard, une librairie header only.

Attention, on ne peut pas tout faire en header-only et si tu as trop de fichiers, tu vas augmenter le temps de compilation.

[Invité]

Oui avec mon système il faut recompiler, cependant :

C'est une petite lib donc, ce n'est pas bien grave.

Avec du code templatisé c'est beaucoup plus simple de tout mettre dans un .h.

Ton système force à ce que mon moteur soit linké dynamiquement, car je dois posséder des .dll ou bien des .so, chose plus difficile à générer que des .a.

Pour le reste j'ai dis des bêtises.

Bref, il ne faut pas toujours écouter ce que dit Neckara, parfois, il dit vraiment n'importe quoi, en plus il est méchant, je le plussoie et lui il me moinsoie.

[Neckara]

Comme je l'ai dit, 3 jours pour mes tests.

Je viens d'ajouter :

• mesure du temps des tests ;
• affichage des ligne, fichier et condition ;
• répétions de série de tests avec des valeurs différentes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE_SERIE_REAPETABLE_D(Exceptions, toto,
                          int i COMMA int j COMMA int k=3,
                          i     COMMA j     COMMA k
                          )
 
TEST( nothrow )
    {
        std::cerr << j << std::endl;
    };
 
 
END_SERIE_REAPETABLE_D(Exceptions, toto)
 
 
SERIE_REAPETABLE(3, toto, "tiiet", 7 COMMA 9);
 
int main(void)
{
    SERIE_REAPETABLE(0, toto, "tit", 7 COMMA 4);
    SERIE_REAPETABLE(1, toto, "tiit", 7 COMMA 3 );
 
    return 0;
}

Il ne manque plus que :

• la doc ;
• intégrer le système de module.

Mais je vais prendre mon temps pour terminer tout cela.

EDIT: et en plus ils peuvent êtres template maintenant \o/

[Neckara]

yildiz-online va m'adorer.

Je pense réinventer une autre roue : un "dom" pour TLV.
Réinventer est un bien grand mot sachant que je n'ai trouvé pour le moment aucune bibliothèque mature le permettant.

Je proposerais, via ce "dom" de lire/enregistrer des fichiers XML très simplifiés. Donc pas la peine d'aller rechercher une dépendance externe pour si peu.
Le but du "dom" étant principalement le TLV, le XML associé doit donc avoir quelques restrictions.

Ainsi, on pourra enregistrer les résultats dans un format assez souple et structuré.
Le traitement des résultats se fera via ce format/via la structure dom ce qui permettra d'avoir une interface unifiée.

[yildiz-online]

On en a pendu pour moins que ça!

Sinon, par DOM tu veux dire un parser XML je suppose, y a SAX aussi.
Pour la validation XML, y a les DTD ou les schema.

Aucune idée si en c++ y a des implémentations(certainement mais j'en sais rien) donc pas de corde pour aujourd'hui!

PS: attention que c'est moins simple que ça en a l'air à implémenter: l'escaping des caractères, la gestion des attributs, la localisation des éléments dans l'arbre(xpath)... ça va faire du boulot

[Neckara]

Aucune idée si en c++ y a des implémentations(certainement mais j'en sais rien) donc pas de corde pour aujourd'hui!

Pour DOM/XML très certainement, pour TLV, je pense qu'il en existe mais je n'ai rien trouvé et je ne sais pas si je pourrais en trouver autrement que des bouts de codes sur des forums.

PS: attention que c'est moins simple que ça en a l'air à implémenter: l'escaping des caractères, la gestion des attributs, la localisation des éléments dans l'arbre(xpath)... ça va faire du boulot

Comme je l'ai dit, j'utilise des "des fichiers XML très simplifiés".

En gros ne gère que :

Balise : <NOM/>
Balise : <NOM>CONTENU</NOM>
CONTENU : CONTENU_SANS_BALISES | CONTENU_AVEC_BALISES
CONTENU_SANS_BALISES : TEXTE | <![CDATA[TEXTE]]>
CONTENU_AVEC_BALISES : SPACE | BALISE
CONTENU_AVEC_BALISES : CONTENU_AVEC_BALISES CONTENU_AVEC_BALISES

C'est donc déjà bien plus simple.
Je viens de finir, ça plantera juste si le fichier XML ne respecte pas ma syntaxe restreinte. .
La flemme d'utiliser Flex/Bison, je l'ai fais à la main.


Maintenant me reste plus qu'à :

• enregistrer mes résultats au format TLV ou XML (comme je le souhaite) ;
• ajouter la date de début du test ;
• faire un requêteur type XPATH en plus simple. Maintenant que j'ai ma structure, faut bien que je m'amuse avec ^^

[Neckara]

Donc actuellement il me reste à :

• fusionner Element et ElementValue ;
• avoir une méthode rootElement() ;
• avoir un requêteur XPATH (assez simple) ;
• ajouter la date de lancement des tests ;
• renommer UnitTestsManager en UnitTestsSession ;
• mettre les résultats des tests dans mon "dom" ;
• charger des UnitTestsFile à partir de fichiers binaires.

Ensuite, je gèlerais le projet pour sortir une release 0.1.
Elle correspondra aux tests unitaires + "DOM" TLV.

Pour rassurer yildiz-online, le XML n'est là que pour tester et déboguer.
En effet le TLV n'est pas très lisible pour un humain, mais très facilement lisible pour une machine.
J'ajouterais sûrement un parseur XML pour avoir quelque chose de plus complet et de plus stable dans une version future.
Il serait même possible d'intégrer en importation/exportation vers une BDD SQL.

La v0.2 intégrera ma gestion des modules que je modifierais pour intégrer mon "DOM" pour la représentation des données.
C'est vraiment très pratique pour manipuler des données et offre une interface unifiée.
Exemple :

Compter le nombre de tests échoué.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

root.request("count( UnitTest[UnitTestLine/State == 'OK'] )");

Compter le nombre d'UnitTest dont un des UnitTestLine a un State égal à "OK".

En C++, cela donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int count = 0;
for(const UnitTestsFile &  f : s)
    for(const UnitTestsSerie &  se : f)
        for(const UnitTest &  t : se)
        {
            bool isOk = false;
            for(const UnitTestLine &  l : t)
                if( l.state() == LT::ObjectState::OK )
                    isOk = true;
            count += isOk;
        }
}

Je ne sais pas quelle syntaxe vous préférez .


Pour la sortie de la v0.1, je vais devoir :

• figer/geler le dev ;
• faire la doxygen, les tutoriels, le débogue et le refactoring ;
• ajouter un changelog ;
• regarder pour l'installation des bibliothèques (make install) ;
• changer les versions des modules existants si besoin ;
• mettre le copyright de partout, mettre en ligne la doc ;
• mettre à jour le dépôt git et taguer le commit de release ;
• faire un zip de téléchargement pour la release ;
• et enfin annoncer la nouvelle version ici, sur Twitter et peut-être sur des sites concurrents.

Après pour les tutoriels peut-être qu'ils intéresseront LW pour être publiés sur DVP (?). Enfin, on en est pas encore là ^^.

Pour la v0.2, bis repetita, mais je pense rajouter des tutoriels sur l'organisation interne afin que chacun puisse nous rejoindre et proposer son propre module.

[Invité]

*ressort de sa grotte vidéoludique*
Ah bah! Je m'absente quelques jours et c'est le bazar

Plus sérieusement, pourquoi je trouve que git est une bonne grosse régression :
- j'ai utilisé CVS et SVN en comprenant comment s'en servir rapidement (là même avec des articles et des explications live j'ai toujours rien compris)
- si j'ai bien compris, on fork à chaque commit , quel est l'intérêt par rapport aux branches gérées manuellement où on faisait ça quand c'était nécessaire(et surtout comment on fait pour avoir une branche principale sur laquelle tous les devs se raccrochent et poussent leurs modifs? parce que le coup de la meilleure branche heuuuu... dans le monde pro??)
- on pousse des versions complètes ce qui est consommateur en espace disque (quel intérêt, si ce n'est tuer encore plus de pingouins en réduisant encore la taille de la banquise), et en plus, quand on a tout le code en vrac et que seul certains fichiers/classes sont au point, on fait comment?
Bref, pour moi, git sent le paté (peut être je suis trop vieille??)

Sinon pour les tests unitaires et l'histoire des dépendances; ce que j'en sais (en Java..) quand on utilise pas Maven ni Ant et qu'on y va en mode bourrin... c'est qu'il faut faire un projet séparé du code source.
Normalement un bon jeu de test n'intervient absolument pas sur le code source du projet testé (sinon c'est qu'on est mauvais). Donc doit pas y avoir à introduire de dépendances dans le projet testé.

Ensuite dans un jeu de test, on veut surtout vérifier que quelquechose qui est vrai une fois est toujours vrai. C'est pour ça qu'on va coder pleins de trucs en dur (du genre on assume que la structure machin n'est pas nulle ou que la variable truc vaut 3; sinon c'est que ça va pas et le test échoue).

L'intérêt des tests automatisés s'étend avec le nombre de lignes de code écrites. Les humains étant imparfaits, on fait tous des erreurs. C'est bête de se retrouver au bout de 6 mois à décrypter 10,000 lignes de code parce qu'on a oublié d'initialiser un tableau... ou qu'on a fait un boucle infinie par erreur...

[Neckara]

- j'ai utilisé CVS et SVN en comprenant comment s'en servir rapidement (là même avec des articles et des explications live j'ai toujours rien compris)

La plupart des tutoriels que je vois sont très mauvais en effet.
J'ai vraiment compris ce que je faisais après un très bon cours de 2h.

- si j'ai bien compris, on fork à chaque commit

Euh… non.
Les fichiers modifiés sont en effets dupliqués, mais pour les autres, tu n'as pas de duplications, c'est à base de "pointeurs". Ceci facilite grandement les git checkout.

et surtout comment on fait pour avoir une branche principale sur laquelle tous les devs se raccrochent et poussent leurs modifs? parce que le coup de la meilleure branche heuuuu... dans le monde pro??)

On ne va pas laisser les devs pousser eux-même sur la branche principale !
Les devs envoient une pull request à l'intégrateur et c'est lui qui va récupérer les modifications à partir du dépôt publique du devs sur son repo privé. Il intègre les modifications, teste le tout, … puis il pousse le tout sur le "holy repo". Et c'est le seul qui a le droit de faire cela.

- on pousse des versions complètes

Seulement pour les fichiers modifiés. Ce n'est pas énorme pour la mémoire et cela permet de revenir à un commit antérieur ou de changer de branche presque instantanément, même si tu as 10 000 commits.

quand on a tout le code en vrac et que seul certains fichiers/classes sont au point, on fait comment?

Tu fais une branche. Tu intégreras la branche à la branche principale quand ton code sera à nouveau correct.
Ou tu ne pousse que les fichiers "au point" sur la branche principale.

Ensuite dans un jeu de test, on veut surtout vérifier que quelquechose qui est vrai une fois est toujours vrai. C'est pour ça qu'on va coder pleins de trucs en dur (du genre on assume que la structure machin n'est pas nulle ou que la variable truc vaut 3; sinon c'est que ça va pas et le test échoue).

On ne peut malheureusement pas tester avec toutes les valeurs possibles, c'est pour cela que je propose des tests non déterministes.
En gros, si on teste 10 valeurs dans une session de tests, avec 100 sessions, on aura testés 1 000 valeurs.
On trouvera des bugs jusqu'alors inconnu, on enregistre la SEED() puis on peut alors déboquer.

L'intérêt des tests automatisés s'étend avec le nombre de lignes de code écrites. Les humains étant imparfaits, on fait tous des erreurs. C'est bête de se retrouver au bout de 6 mois à décrypter 10,000 lignes de code parce qu'on a oublié d'initialiser un tableau... ou qu'on a fait un boucle infinie par erreur...

+1

[Invité]

Les tests peuvent se faire facilement dans le main avec un code minimal qui appel plusieurs fois la fonction. (qu'elle soit membre ou pas)

Et avec le débogueur je m'en sors tout le temps.

Je ne comprend absolument pas l'intérêt de tout votre bazar.

[Neckara]

Sauf que :

• si tu testes une classe qui utilise d'autres classes non-implémentées, tu vas polluer ton projet avec des classes écrites à la va-vite juste pour le test ;
• une fois ton test terminé, tu vas le supprimer, donc tu devras réécrire tout ton test quand tu auras une erreur. C'est comme déboguer avec les std::cout, c'est pas viable ;
• ton test sera peu/mal formalisé, tu risques donc de passer à côté de plusieurs choses ;
• ton test va prendre du temps à écrire ;
• si tu passes ton code à quelqu'un d'autre, comment saura-t-il quels tests faire ? Les tests sont aussi une sorte de documentation.
• ce n'est pas viable si on tente de faire de la TDD (développement dirigé par les tests).
• si tu gère une bibliothèques ou un moteur, c'est bien de pouvoir garantir à tes utilisateurs que tu n'as rien cassé.

[yildiz-online]

Les tests peuvent se faire facilement dans le main avec un code minimal qui appel plusieurs fois la fonction. (qu'elle soit membre ou pas)

Et avec le débogueur je m'en sors tout le temps.

Je ne comprend absolument pas l'intérêt de tout votre bazar.

Parce que les tests unitaires sont comme leur nom l'indique... unitaires, ce ne sont pas des tests end 2 end, ils vont tester les différents paths possibles dans une méthode de manière à vérifier qu'elle se comporte bien de la manière attendue.
Pour se faire on utilise donc généralement des simulacres (mock objects) afin de s'assurer que le comportement sera bien testé sans être influencé par une entrée extérieure non validée.

Si tu n'as jamais programmé d'application conséquente, c'est normal de ne pas en ressentir le besoin, mais dès que les couches se multiplient et que la complexité augmente, un test basique ne peut plus être sûr, et de toute façon, les tests d'intégrations ne pourraient jamais couvrir tous les cas possibles.

[Invité]

Ha, ok, non je n'ai jamais fait de projet très conséquent tel que les votre, c'est pour cela certainement que je n'en voyait pas l'utilité. (Surtout pour une seule personne comme moi qui développe dans son coin des petits projets et un petit moteur, qui ne fait rien d'autre que de réinventer une plus petite roue.)

[Woum_]

J'ai peut-être loupé l'info, mais les tests unitaires sont surtout utile à mes yeux pour permettre lors d'un ajout de code de voir que le code précédent fonctionne toujours comme voulu. On lance, ça prends 5 secondes, et on valide la cohésion.
C'est de la magie .

[Neckara]

Le chargement des tests à partir des fichiers binaires marche du feux de dieu et du premier coup.

Sérieusement, aucune erreurs, c'est pas normal…
Enfin bon, plus que le requêteur XPATH à faire avant de geler le dev.
Je pense que ce devrais être assez rapide.

Je vais avoir besoin de testeurs pour tester tout cela .