Discussion :

[Neckara]

Un petit article pour expliquer très rapidement comment fonctionne le site et quelles sont ses possibilités :
http://last-project.ovh/fr/projects/...rials/website/

Vous verrez que je me suis bien amusé. En fait le site utilise une sorte de pseudo-HTML appauvrit pour construire les pages.
Je ne vous parle pas du mécanisme en XSLT derrière ( ), juste de la base Dabou-friendly.

[Neckara]

Ce qui était prévu :

• d'ici vendredi, système de module terminé ;
• pendant ma semaine de vacances, docs, tutoriels, deux-trois trucs sur le site ;
• 4 semaines pour la fenêtre et le module de paramètres ;
• 2D, 2 semaines ;
• sons, 1 semaine ;
• gestions événements, 3 semaines.

J'ai bien fini le système de module, je l'ai même un peu débogué.
J'ai aussi fait "2-3 trucs" sur le site.

Mais je suis vraiment impatient de commencer Last Escape.
Normalement, j'ai encore la documentation et quelques tutoriels à rédiger, mais je pense que je le ferais ultérieurement.

Je pense donc me concentrer tout d'abord sur :

• module fenêtre ;
• début d'affichage 2D avec un module 2D ;
• affichage de la lumière ;
• module XML pour charger les cartes ;
• module son pour l'ambiance.

Je posterais un sujet pour Last Escape dès que je commencerais l'affichage de la lumière.

[Neckara]

Chose promise, chose due :

Sujet de présentation de Last Escape.

[Neckara]

Bonjour,

Mes examens commencent la semaine prochaine et s'étendent pendant tout le mois d'avril (exams TPs/Soutenance projet) pour se finir par une semaine d'examens.
Je commence donc à avoir de plus en plus de temps libre, mais que j'utilise pour commencer mes révisions.

Juste après, je pars théoriquement en stage à l'étranger pour 3 mois. Je ne sais donc pas encore si j'aurais une connexion internet, ni même si j'aurais du temps.
Après un petit mois de vacance, je reprendrais les cours en 3A, j'aurais encore moins de temps libre .

Mais bon, j'ai déjà réussi à faire 2-3 choses qui étaient en attente depuis plusieurs années (ex. sauvegarde automatique de mes fichiers ).
Je ne sais donc pas encore comment je vais m'en sortir. Enfin bref, on verra bien .

[Invité]

Comme on dit, Merde! pour les exams.

[Neckara]

@akd, merci. Premier exam de TP passé avec succès \o/.


Il y a quelques jours on a eu un intervenant externe qui nous a présenté les tests unitaires. Le cours était très intéressant… et bien sûr, je n'ai désormais plus qu'une seule obsession :
Coder mon propre système de tests unitaires !

Déjà que j'avais résisté à l'envie de coder un moteur pour créer des sites web en C++ (à base de DOM)… je n'ai pas pu résister pour les tests unitaires .



Bon, comme je l'ai dis, je n'ai plus beaucoup de temps et cela risque de durer un certain temps. Donc si je code, ce n'est pas un week-end à fond dessus, mais 1h grappillée par ci-par-là avec parfois des interruptions de plusieurs semaines. Déjà que lorsque je ne code pas pendant 1 semaine, j'ai l'impression que ça fait une éternité…

Le problème, c'est donc qu'il me faudra me replonger dans le code, voir où j'en étais, ce qui marchait, etc… Or c'est le bon moyen pour oublier quelque chose. Par exemple, pour les shader, j'ai juste ajouté le code à la bourrin. Il faut que je réintègre tout cela plus proprement avant de continuer le code.


Les tests unitaires sont donc très intéressants pour moi :

• ils évitent la régression de code ;
• une fois des tests écrits, je peux éventuellement me trouver un esclave pour écrire le code à ma place ;
• je peux écrire des briques de bases indépendamment d'autres briques, cela aide à réduire le couplage entre classes, mais aussi à éviter d'intégrer du code à la bourrin pour tester un petit truc, je peux par exemple tester des collisions sans aucun affichage ;
• dès que je lance les tests, je verrais directement ce qui marche ou pas, donc où j'en suis actuellement ;
• les tests auto-documentent mes classes, donc moi qui n'aurait très certainement pas le temps de tout documenter, cela sera d'une grande aide ;

Bon, je pense que ce sera relativement rapide à coder.
Une fois fini, je pense que je pourrais sortir une première version du moteur, juste avec les tests et d'autres petits outils.

Je pense aussi que je vais supprimer mes diverses branches github. C'est très intéressant quand on avance vite, mais là, vu mon rythme, je pense que j'ai autre chose à faire qu'à gérer autant de branches, d'autant plus que je n'ai rien de distribuable à ce jour.

[Invité]

Je vais t'avouer, j'ai beaucoup de mal avec Github (en fait je trouve même que le concept de base est une régression par rapport à ce que permet SVN et qu'il tue plus de pingouins)

Concernant les tests unitaires, voici un petit conseil :
Dans le cas présent tu as du code déjà existant (code "Legacy" comme on dit)
Le système de test automatisé est donc un peu différent de ce que tu ferais en Test Driven Development (développement dirigé par les tests); puisque tu écris les tests à postériori.

Le plus simple dans ce cas est de commencer par écrire des tests pour les nouveaux éléments et ensuite reprendre petit à petit les anciens.
Le problème sur les anciens, c'est qu'ils ont peut être une adhérence forte entre eux; et que donc tu ne pourras pas forcément tester un bout de code séparément du reste. En règle général, dans ce cas on évite de tout péter et tout refaire et on s'adapte (en sachant donc que les tests seront pas 100% fiables sur cette partie).

A priori, C++ à l'avantage que tout est .H à la base, donc il y a déjà des "interfaces" (contrairement à Java ou C# où il faut faire ses interfaces avant de coder). J'ai vu aussi qu'il y avait pas mal de bibliothèques pour bouchonner les bouts de programme (mocker); donc avec ccpUnit ça devrait le faire!

On en parle un de ces 4 si tu as du temps (par contre je suis en grotte vidéoludique ce week end).

[Neckara]

Bon, je me suis un peu emporté

Voici un début de test :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
TEST_FILE_D(nullC);
TEST_FILE_D(nullB);
 
 
 
TEST_SERIE_D(nullC, A)
 
    INIT_FUNCTION( [](){ });
    BEFORE_FUNCTION( [](){ });
    AFTER_FUNCTION( [](){ });
    DESTROY_FUNCTION( [](){ });
 
    TEST(Mon test 1)
    {
        return LT::UnitTest::ALEA;
    };
 
 
    TEST(Mon test 2)
    {
        return LT::UnitTest::OK;
    };
 
END_SERIE
 
TEST_SERIE_D(nullC, B);
 
    TEST(Mon test 4)
    {
        return LT::UnitTest::WARNING;
    };
 
    TEST(Mon test 3)
    {
        return LT::UnitTest::OK;
    };
 
END_SERIE
 
 
TEST_SERIE_D(nullB, C);
 
    TEST(Mon test 5)
    {
        return LT::UnitTest::ERROR;
    };
 
    TEST(Mon test 6)
    {
        return LT::UnitTest::OK;
    };
END_SERIE
 
TEST_SERIE_D(nullB, D);
 
    TEST(Mon test 7)
    {
        return LT::UnitTest::OK;
    };
 
    TEST(Mon test 8)
    {
        return LT::UnitTest::OK;
    };
 
END_SERIE
 
 
int main(void)
{
 
    LT::UnitTestsManager testManager;
 
    ACTIVE_SERIE(A);
    ACTIVE_SERIE(B);
    ACTIVE_SERIE(C);
    ACTIVE_SERIE(D);
 
#warning Load tests
 
    testManager.addUnitTestsFile("nullC", &nullC);
    testManager.addUnitTestsFile("nullB", &nullB);
 
    testManager.launch();
 
 
    LT::UnitTestsPrinter printer(testManager);
 
 
    return 0;
}

Ce qui donne :

#####################
########## BEGIN TEST
#####################






=======================
====== 1/2 nullC
=======================




======
== 1/2 A
======
1/2 [A] Mon test 1
2/2 [O] Mon test 2
======
== Resume
======
1/2 [A] Mon test 1
======
== W:0 A:1 X:0 on 2 tests
======


======
== 2/2 B
======
1/2 [W] Mon test 4
2/2 [O] Mon test 3
======
== Resume
======
1/2 [W] Mon test 4
======
== W:1 A:0 X:0 on 2 tests
======


=======================
====== Resume tests
=======================
1/2 of 1/2 [A] Mon test 1/A
1/2 of 2/2 [W] Mon test 4/B
======================
====== W:1 A:1 X:0 on 4 tests
======================
====== Resume Series
======================
1/2 [A] A W:0 A:1 X:0
2/2 [W] B W:1 A:0 X:0
======================
====== W:1 A:1 X:0 on 2 series
======================






=======================
====== 2/2 nullB
=======================




======
== 1/2 C
======
1/2 [X] Mon test 5
2/2 [O] Mon test 6
======
== Resume
======
1/2 [X] Mon test 5
======
== W:0 A:0 X:1 on 2 tests
======


======
== 2/2 D
======
1/2 [O] Mon test 7
2/2 [O] Mon test 8
======
== Resume
======
All is OK !
======
== W:0 A:0 X:0 on 2 tests
======


=======================
====== Resume tests
=======================
1/2 of 1/2 [X] Mon test 5/C
======================
====== W:0 A:0 X:1 on 4 tests
======================
====== Resume Series
======================
1/2 [X] C W:0 A:0 X:1
======================
====== W:0 A:0 X:1 on 2 series
======================






#####################
########## RESUME TESTS
#####################
1/2 of 1/2 of 2/2[X] Mon test 5/C/nullB
1/2 of 1/2 of 1/2[A] Mon test 1/A/nullC
1/2 of 2/2 of 1/2[W] Mon test 4/B/nullC
#####################
########## W:1 A:1 X:1 on 8 tests
#####################
########## RESUME SERIES
#####################
1/2 of 2/2[X] C/nullB W:0 A:0 X:1
1/2 of 1/2[A] A/nullC W:0 A:1 X:0
2/2 of 1/2[W] B/nullC W:1 A:0 X:0
#####################
########## W:1 A:1 X:1 on 4 series
#####################
########## RESUME FILES
#####################
1/2 [A] nullC W:1 A:1 X:0 on 2 series
2/2 [X] nullB W:0 A:0 X:1 on 2 series
#####################
########## W:0 A:1 X:1 on 2 FILES
#####################

Ce n'est que l'affichage des résultats, c'est donc très facilement changeable.
On pourrait par exemple imaginer une fenêtre 2D pour afficher ces résultats avec plein de petites couleurs.


Il ne manque plus qu'à :

• ajouter des outils de tests (asserts, exceptions, signaux, nettoyage, messages d'erreurs) ;
• compter les temps d’exécution des tests unitaires ;
• charger les tests comme des modules.

Je pense que la syntaxe est assez user-friendly.

Je vais t'avouer, j'ai beaucoup de mal avec Github (en fait je trouve même que le concept de base est une régression par rapport à ce que permet SVN et qu'il tue plus de pingouins)

Une régression ? oO
Tu viens de me choquer là !

[Neckara]

Je viens de poster sur le forum C++ pour avoir plus d'avis sur mes tests unitaires :
http://www.developpez.net/forums/d15...n/#post8178949

[LittleWhite]

Je n'ai pas compris pourquoi vous réimplémentiez votre propre moteur de test unitaires.

[Neckara]

Parce que c'est cool.

Je suis très fainéant de nature, donc moins l'écriture des tests est verbeux, mieux je me porte.
Comme on a pas l'air de beaucoup parler de moteurs de tests unitaires en C++, je n'ai pas beaucoup d'exemples, mais de ce que je vois, cela me parait trop verbeux.
La flemme de créer une classe quand je veux écrire un test.

Après, je ne trouve pas vraiment d'exemples intéressant de code de tests unitaire créé avec un moteur existant.
De plus, pour ce qui est de :

• configurer le "contexte" avant de lancer un test (BEFORE/AFTER) ;
• la répétition de tests ;
• capturer les exceptions ( POLICY_XXX_ON_CATCH ), …

Je n'ai pas l'impression que tous les moteurs le font (?)

Au final, je pense que cela a été plus rapide et amusant de créer mon moteur que de chercher et tester les existants…

Après, c'est aussi pour éviter au possible d'avoir des dépendances et d'adapter mon moteur à mon système de modules.

[yildiz-online]

http://sourceforge.net/projects/cppunit/

[Neckara]

Le wiki est vide


La seule doc que je vois, c'est les exemples après avoir téléchargé le zip :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
template  class BoardGameTest : public CppUnit::TestCase
 {
   protected:
     GAMECLASS    *m_game;
        public:
     BoardGameTest (string name) : CppUnit::TestCase (name)
      {}
 
          BoardGameTest (CppUnit::TestSuite *suite) : CppUnit::TestCase ("")
      {
        suite->addTest (new CppUnit::TestCaller ("testReset", testReset));
      }
 
          int countTestCases () const
     { return 1; }
 
          void setUp ()
      { m_game = new GAMECLASS; }
 
 
          void tearDown ()
     { delete m_game; }
 
          void testReset ()
      { assert (m_game->reset ()); }
      };
 
 
  template  class ChessTest : public BoardGameTest
 {
   public:     ChessTest (string name) : BoardGameTest (name)
      {
     }
 
          ChessTest (CppUnit::TestSuite *suite) : BoardGameTest (suite)
      {
 
        suite->addTest (         new CppUnit::TestCaller ("testNumberOfPieces", testNumberOfPieces)); 
    }
 
          void testNumberOfPieces ()
      {
        assert (m_game->numberOfPieces () == 32);
      }
 };

C'est super-verbeux et en plus les tests ne s'enregistrent ni se lancent automatiquement et j'ai pas l'impression qu'on ai beaucoup d'explications sur pourquoi m_game->numberOfPieces () doit valoir 32.

Je ne vois pas beaucoup de fonctionnalités dans cet exemple, pourquoi utiliser cette dépendance quand je peux faire autant en 2heures ? Je ne sais pas ce que vaut réellement cppunit, mais l'exemple ne me fait pas vraiment rêver. Le moteur de boost me semble bien plus avancé.

Bon, je ne veux pas faire le difficile, mais ça me déçoit un peu.


Pour comparaison :

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
 
template  class ChessTest : public BoardGameTest
{
   public:
      ChessTest (string name) : BoardGameTest (name)
      {
      }
 
      ChessTest (CppUnit::TestSuite *suite) : BoardGameTest (suite)
      {
            suite->addTest (
                       new CppUnit::TestCaller ("testNumberOfPieces", testNumberOfPieces));
      }
 
      void testNumberOfPieces ()
      {
              assert (m_game->numberOfPieces () == 32);
      }
 
 };
 
ChessTest<Chess> ct();

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
SERIE_TEST(ChessTest)
{
      Game * m_game;
      BEFORE_FUNCTION
      {
             m_game = new Game();
      }
 
      AFTER_FUNCTION
      {
            delete m_game;
      }
 
      TEST(testNumberOfPieces)
      {
           FAIL_ON(m_game->numberOfPieces () == 32, "A chess board have 32 pieces, we use this rules : [link]");
      }
 
 } END_SERIE

J'en ai même profité pour rajouter des règles (BEFORE_FUNCTION et AFTER_FUNCTION) pour garantir le contexte des tests suivants, après tout, on fait des tests unitaires.
Bon, c'est vrai que mon code m_game = new Game(); n'est pas template, mais ce n'est pas vraiment une gêne pour moi (particularité avec mes systèmes de modules).

C'est vrai que ce pourrait être intéressant, je vais y réfléchir. Tout comme afficher la condition non-respectée dans les logs peut-être intéressant.

EDIT : désolé, mais tous les retours à la lignes ont sauté pendant l'édition de ce message.

[yildiz-online]

Pas testé(je teste pas unitairement mon code c++, juste tests d'intégrations qui partent de java/ruby et descendent jusqu'à la couche c++) donc je peux pas juger, ils décrivent ça comme le pendant de junit, qui est standard de facto en java(où c'est forcément beaucoup moins verbeux du fait des annotations).

J'ai effectivement lu beaucoup de bien du framework de boost pour le testing, mais pas testé non plus.

[Neckara]

J'ai effectivement lu beaucoup de bien du framework de boost pour le testing, mais pas testé non plus.

Apparemment, ils font à peu près comme moi, avec des macro "Début de série de test" et "fin de serie de test".

Le problème, c'est que boost est une dépendance assez lourde, surtout pour des petits projets.
Après, je pense (d'après ce que j'en ai vu) que les tests unitaires ne sont pas assez répandus en C++, la preuve, combien d'IDE C++ intègrent un outil pour les tests unitaires ?

Moi j'ai besoin des tests unitaires pour mon système de modules. Ainsi, je donne l'interface + le comportement (=tests unitaires) et je pourrais laisser les autres se débrouiller et proposer ce qu'ils veulent.

[yildiz-online]

Pas besoin de tout embarquer dans boost, c'est modulaire.

Eclipse CDT n'a pas une trop mauvaise intégration mais ça reste pas trivial à mettre en place, c'est clair.
Ptet suivre CLion, de jetbrains, ils viennent du monde java(et ont le meilleur ide java), donc je suppose qu'il vont pas délaisser le controle qualité

[Neckara]

Pas besoin de tout embarquer dans boost, c'est modulaire.

Ouais je sais, il y a même des bibliothèques header-only.

Le problème, c'est qu'on commence avec une bibliothèque boost, puis on en rajoute une autre pour les expressions régulières, puis une autre pour les vecteurs de référence, puis encore une autre pour faire le café .

Sur un autre projet, je l'utiliserais sans me poser de questions, mais là, le but est de justement limiter au maximum les dépendances.
Après, je ne connais pas très bien boost mais :

• j'ai l'impression que j'ai 2-3 trucs tordus que boost n'a pas ;
• j'aime pas leur boost_check_equal(expr, expr), je ne comprend pas son utilité par rapport à un assert(expr);

Eclipse CDT n'a pas une trop mauvaise intégration mais ça reste pas trivial à mettre en place, c'est clair.
Ptet suivre CLion, de jetbrains, ils viennent du monde java(et ont le meilleur ide java), donc je suppose qu'il vont pas délaisser le controle qualité

Oui, ils viennent tous du monde Java. Pour les IDE qui viennent du monde C++, je ne vois pas de d'outils pour les tests unitaires.

Après, ça se comprend. En C++, c'est pas comme en Java, on sait ce que l'on fait, nous, donc pas besoin de tester.

[yildiz-online]

"Sur un autre projet, je l'utiliserais sans me poser de questions, mais là, le but est de justement limiter au maximum les dépendances."

(pas fini mon café -> pas trouvé le bouton citation...)

Quelle est la raison de vouloir limiter au maximum les dépendances?

[Neckara]

Disons que quand on ajoute une dépendance, on devient dépendant de la dépendance avec tout ce que cela implique :

• difficile de changer de dépendance ;
• difficile de changer de version ;
• et si le dev de la dépendance est abandonnée ?
• et si demain je veux exécuter mon code sur une plateforme sur laquelle la dépendance n'est pas supportée ?
• ce qu'on doit ensuite itérer avec les dépendances des dépendances.

Et je ne parle pas des mises à jour ou du choix qu'à l'utilisateur final…

Le but de mon moteur, c'est de dire :

De toute façon on sera obligé d'intégrer des dépendances, mais on va le faire proprement.

Au lieu de dépendre d'une dépendance, on va dépendre d'une interface, d'une API.
Et au lieu d'intégrer la dépendance à notre code, on va créer un module (fichier .lem) qu'on pourra facilement activer/désactiver/remplacer sans tout recompiler.
Dedans, on implémentera l'interface donné avec la dépendance de notre choix.

Donc l'utilisateur final peut choisir et n'importe quel dev peut facilement proposer à tout le monde sa propre implémentation.

Le problème de cela, c'est que je ne peux me permettre aucune dépendance dans le "noyau", le truc qui gère les modules en sommes.
Et comme mes tests peuvent porter sur des éléments du noyau, il ne faut pas qu'ils dépendent du noyau. Donc je vais même très certainement avoir une duplication de code pour le noyau des tests.

Car oui, les tests suivent le même principe que les dépendances, c'est un fichier binaire .lt.
Ce qui facilite les màj, facilite l'échange de tests sans recompiler, idem pour l'activation/désactivation.

[yildiz-online]

Disons que quand on ajoute une dépendance, on devient dépendant de la dépendance avec tout ce que cela implique :

• difficile de changer de dépendance ;
• difficile de changer de version ;
• et si le dev de la dépendance est abandonnée ?
• et si demain je veux exécuter mon code sur une plateforme sur laquelle la dépendance n'est pas supportée ?
• ce qu'on doit ensuite itérer avec les dépendances des dépendances.

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

Le problème de cela, c'est que je ne peux me permettre aucune dépendance dans le "noyau", le truc qui gère les modules en sommes.
Et comme mes tests peuvent porter sur des éléments du noyau, il ne faut pas qu'ils dépendent du noyau. Donc je vais même très certainement avoir une duplication de code pour le noyau des tests.

Car oui, les tests suivent le même principe que les dépendances, c'est un fichier binaire .lt.
Ce qui facilite les màj, facilite l'échange de tests sans recompiler, idem pour l'activation/désactivation.

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.

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.