Rivages (DBark v2)
#11
(10-04-2011, 07:52 PM)Sephi-Chan a écrit : As-tu essayé Cucumber pour les tests ? Et pourquoi développer ton propre framework de test plutôt qu'utiliser PHPSpec ou PHPUnit ?
cucumber, pas regardé
j'avais voulu rentré dans php unit, et puis finalement ....

je trouve très simple ma méthode

$test->NewCategory('...... Recherche sur Id Existant avec une valeur trop faible');
$test->NewCase('méthode WhatIs',
'', NULL, 'WhatIs', array( $sys20_Present, array(SEARCH_ID, 2, 30)) );
$test->NewCase('méthode IsAvailable',
false, NULL, 'IsAvailable', array( $sys20_Present,2, 30) );

$test->NewCategory('...... Recherche sur Id Existant avec une valeur accessible à 30');
$test->NewCase('méthode WhatIs',
'sc = 100/ plty = 0/ sys = [30 avec talent "rapide a 2" et expérience qui fera passer à 3]->modEnergy->Present(2,30)<br/>',
NULL, 'WhatIs', array( $sys30_Present, array(SEARCH_ID, 2, 30)) );
$test->NewCase('méthode IsAvailable',
true, NULL, 'IsAvailable', array( $sys30_Present,2, 30) );

et surtout ça m'a éclaté de le construire 2 j'ai dû passé 30 minutes à construire le premier jet, puis au global, avec les évolutions à peine deux heures
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#12
Tu sais les tests permettent généralement de ne pas se fouler sur la documentation car ils servent de mode d'emploi de l'API

Hors, là, sans vouloir t'offenser, c'est un peu le foutoir pour comprendre comment ça marche ton truc
Répondre
#13
bah

$test->NewCategory pour une ligne d'entête, avec comme entête le libellé passé en paramètre

$test->NewTest pour un cas test, avec comme paramètres dans l'ordre

libellé du test
résultat attendu
référence de l'objet (si appel d'une méthode, null si pas un objet mais une fonction)
nom de la méthode
tableau des paramètres à envoyer


[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#14
aller, un petit dernier suite aux nombreux mails d'afficionados (bon en fait j'ai reçu qu'un mail :p)

l'état d'avancement, évidemment les % ne veulent rien dire exactement, n'ayant pas définit précisément le périmètre du jeu, mais ça donne une idée :

Priorité 1 : le jeu côté serveur (je suis autonome pour le faire)
liste des fonctionnalités du jeu 70%
architecture du jeu 40%
développement des fonctionnalités du jeu 20%

Priorité 2 : la base de données (je suis à peu près autonome pour le faire, peut être à découvrir les systèmes complémentaires à une bdd genre apc, nosql, etc..)
modélisation donnée 30%
base de données 0%

je développe avec des couches vraiment séparées, la bdd n'existe pas encore 34

Priorité 3 : l'aspect (je ne suis pas du tout autonome sur le graphisme, a peu près sur le design%ergonomie)
imagination design/ergonomie 30%
réalisation design/ergonomie 0%
graphismes (les images) 0%

je développe avec des couches vraiment séparées, la restitution n'existe pas encore 34

Priorité 4 : l'hébergement, et la production (je ne suis pas autonome, et c'est ce qui m'effraie le plus)
choix du service d'hébergement 0%
installation 0%
choix du service de financement 0% (s'il y a financement)
implémentation du financement 0% (s'il y a financement)
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#15
Bonjour,

J'ai lu une partie de ta présentation, très intéressante pour tout le détail de ton organisation pour la partie technique.

Travailles tu toujours sur le projet ? Quelles sont tes dernières avancées ?
Répondre
#16
je rame un peu pour conclure le système générique de résolution d'actions. Je viens en effet d'identifier (en construisant mes cas tests) une erreur dans mon algorithme. Gros coup de bambou surtout que j'ai peu de motivations en ce moment

Mais bon ça reviendra bien^tôt 34 j'espère
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)