Discussion :

[professeur shadoko]

Bonjour à toutes et à tous.

Voilà mon dilemne: je conçois et développe un framework de test (que j'espère publier en open-source en septembre)
Une première version est à la disposition des beta-testeurs ... et en réponse je n'entends qu'un grand silence!
ça m'inquiète beaucoup: serait-il possible que mon concept soit erroné et sans intérêt?
Seule demande jusqu'à présent: comparer l'outil que je propose avec JUnit.

C'est plutot embarassant: autant essayer de comparer une girafe et un éléphant (tous les deux vivent dans la savane et ont des systèmes d'entrée/sortie comparables! ).
De plus je ne suis certes pas la personne la plus qualifiée pour me lancer dans une comparaison (j'ai forcément des points de vue biaisés).

Voici quelques principes qui ont guidés la conception de la chose ... à vous de voir si vous "achetez" les concepts!

- Un truc embarrassant quand un programmeur veut écrire un programme de test est qu'il peut avoir l'impression de re-écrire des évidences.
Le programmeur: "bon mon code calcule un prix TTC à partir d'un prix HT ... qu'est ce qu'il faut rajouter pour tester ça? Que je donne des exemples issus de ma calculette?"
L'outil propose ici de maintenir un "zoo" de valeurs pour des données: n'y a t'il pas des valeurs particulières pour lesquelles le code de calcul ne donne pas le résultat attendu?
Pour donner un exemple si un code utilise une chaîne de caractère que se passe t'il si la chaîne est null, de longueur zero, contient des espaces, des caractères spéciaux, etc...?
L'outil permet d'écrire en un seul test un appel de méthode/constructeur avec une combinatoire de valeurs extraites des zoos. ça donne parfois un nombre important de tests
mais on découvre des bugs surprenants avec ce principe de bombardement stupide ("carpet bombing" en anglais).

- Les compte-rendus de test contiennent les résultats de TOUTES les assertions décrites avec le test (on ne s'arrête pas au premier échec).
Par ailleurs, par défaut, si un test échoue, les autres tests continuent d'être évalués ... sauf si on en décide autrement (par exemple pour des tests de matériel).
Les compte-rendus sortent complètement du dilemne échec/succès: les compte-rendus "bruts" peuvent avoir des états intermédiaire comme "warning" ou
"code non encore réalisé" (l'outil est un langage de script interprété et il permet d'écrire un test sur un code qui n'existe pas encore!).
Ensuite l'outil permet d'annoter les compte-rendus pour mémoriser la prise en compte de nouvelles exécutions des tests
(exemple: "ok ce test échoue, mais ce n'est pas véritablement un bug, c'est un comportement hors limite -ou autre chose-").

- L'outil n'est pas limité aux tests unitaires. Certes on peut utiliser un générateur de tests qui analyse une classe et génère un canevas dans lequel
le programmeur n'a plus qu'à spécifier des ensembles de données et des assertions associées mais il est intéressant de constater que ce canevas
génère des appels de constructeurs et puis ensuite "tube" les instances obtenues avec des programmes qui invoquent les tests de méthode sur chacune de
ces instances. On a ici une première notion de "scenarios": en fait l'outil permet d'écrire des scripts qui déroulent des comportements
et permet de marquer des étapes qui généreront des compte-rendus. Par exemple: on peut tester sur un objet le fait qu'un appel génère une NullPointerException et, dans la foulée,
regarder ce qui se passe avec les codes qui sont traversés par la remontée de cette exception; la version précédente de cet outil était consacrée
à des tests de mécanismes dans lesquels les interactions entre composants étaient complexes et décrites par des scénarios.
On peut également écrire des tests de montée en charge (amusants pour détecter des erreurs algorithmiques).
Notons un moins par rapport à JUnit: les tests sont exécutés dans l'ordre où ils sont définis (la version précédente essayait d'imiter
le coté aléatoire par défaut de JUnit mais ça rendait les codes de scénarios incompréhensibles)

Problèmes: ces spécifications comportent des tas de détails subtils et parfois complexes , on a donc un langage de programmation qu'il faut apprendre à maitriser.
On peut donc s'attendre à une certaine resistance des programmeurs à adopter un tel outil (même si les codes peuvent être très concis!).

Vos commentaires, critiques, suggestions?

Merci

[Laurent 1973]

Qu'elles sont vraiment les manque de JUNIT?
Là est peut-être la grand question.

Pour reprendre tes arguments, voilà comment j'adapterai un xUnit au faiblesse que tu évoques:

• Souvent, on va simplement utiliser un héritage des classes de junit pour ajouter les 2-3 outils pour créer une sorte de "zoo" de valeur dédié à son contrôle et ainsi bouclé sur plein de cas différents sans devoir ré-écrire un test pour chaque cas.
• Normalement, un bon test ne fait qu'un test: donc un seul assert par test => on parcours bien tout les contrôle même en cas d'erreur
• Un environnent xUnit ne se limite bien sur pas au test unitaire, on peux aussi l'utilisé pour des tests d'intégration ou fonctionnel: tout dépend des contraintes d'execussion du tests (besoins de fichier ressources, d'un BD, d'une configuration, ...) pas de l'écriture du tests qui reste finalement très similaire.
  Par contre, pour des tests de performance, de monté en charge, de saisi de valeurs aléatoires ... bref, un certain nombre de tests exploratoire. Dans ce cas, un environment xUnit "condition=>résultat" n'est pas adapté. On cherchera plutôt à logger un "journal" d'actions à analyser ensuite.
• Quid du TDD ?
  Si je veux commencer par écrire les tests, un outil de "générateur de tests" ne me sert bien sur à rien: j'écris dans mes tests mes sénario correspondant à mes specifications et ensuite de code ma fonctionnalité.
  Dans ce cas d'utilisation, comment ton outil de test peut-il plus m'aider face à un xUnit ?

Problèmes: ces spécifications comportent des tas de détails subtils et parfois complexes , on a donc un langage de programmation qu'il faut apprendre à maitriser.
On peut donc s'attendre à une certaine resistance des programmeurs à adopter un tel outil (même si les codes peuvent être très concis!).

Tu l'as dis.
Les environnements de type xUnit sont extrêmement répandu et adopté.
Proposer un nouvelle outil pour les tests, pourquoi pas, mais faut qu'il puisse apporter un vrai plus au développeur qui code son test.
Mais de toute façon, même avec un outil révolutionnaire, son adoption sera forcement long ... voir très long

[tchize_]

- Un truc embarrassant quand un programmeur veut écrire un programme de test est qu'il peut avoir l'impression de re-écrire des évidences.
Le programmeur: "bon mon code calcule un prix TTC à partir d'un prix HT ... qu'est ce qu'il faut rajouter pour tester ça? Que je donne des exemples issus de ma calculette?"
L'outil propose ici de maintenir un "zoo" de valeurs pour des données: n'y a t'il pas des valeurs particulières pour lesquelles le code de calcul ne donne pas le résultat attendu?
Pour donner un exemple si un code utilise une chaîne de caractère que se passe t'il si la chaîne est null, de longueur zero, contient des espaces, des caractères spéciaux, etc...?
L'outil permet d'écrire en un seul test un appel de méthode/constructeur avec une combinatoire de valeurs extraites des zoos. ça donne parfois un nombre important de tests
mais on découvre des bugs surprenants avec ce principe de bombardement stupide ("carpet bombing" en anglais).

J'aime bien l'idée du zoo de valeur, surtout quand ce n'est pas le programmeur qui choisi le Zoo. Si je me fais ma classe utilitaire, je vais surement oublier des cas cas de figure. Genre si je parse une String en Double, je vais penser au null, peut être à la chaîne vide. Mais je vais surement oublier l'utilisateur dont la locale autorise la virgule à la place du ., celui dont le . marque les centaines, etc... Là il y a un certain intérêt. Pour les valeurs spéciales (données nulls, tests oubliés, etc), des outils comme findbug sont très efficace pour mentionner ces erreurs d'un point de vue pratique.
Après, pour être honnête, j'ai du mal à voir comment, concrètement, je peux tester autre chose que des données buisness avec un zoo. Mes tests sont plutôt en général proche du
"Si j'ai X dans la table A et Y dans la table B, je dois retrouve Z dans l'objet O"
"Si je tente de modifier la valeur pour un client dont je ne suis pas responsable, je dois avoir une security exception".

Et ces tests nécessitent de toute façon, chacun, d'aller configurer spécialement la DB pour ce cas précis. Mon "Zoo" deviens un état de DB à aprt entière. Plus compliqué à gérer de manière générique.

- Les compte-rendus de test contiennent les résultats de TOUTES les assertions décrites avec le test (on ne s'arrête pas au premier échec).

junit ->checkThat()

On a ici une première notion de "scenarios": en fait l'outil permet d'écrire des scripts qui déroulent des comportements
et permet de marquer des étapes qui généreront des compte-rendus. Par exemple: on peut tester sur un objet le fait qu'un appel génère une NullPointerException et, dans la foulée,
regarder ce qui se passe avec les codes qui sont traversés par la remontée de cette exception; la version précédente de cet outil était consacrée
à des tests de mécanismes dans lesquels les interactions entre composants étaient complexes et décrites par des scénarios.
On peut également écrire des tests de montée en charge (amusants pour détecter des erreurs algorithmiques).

Est-ce que ça se rapprocherait pas un peu de FitNesse? En gros un wiki où le buisnesss/marketing décrit les règles que doit suivre le programme et un système automatisé derrière traduit le wiki en test unitaires qui valident que le code fonctionne comme les specs le décrivent?

Notons un moins par rapport à JUnit: les tests sont exécutés dans l'ordre où ils sont définis (la version précédente essayait d'imiter
le coté aléatoire par défaut de JUnit mais ça rendait les codes de scénarios incompréhensibles)

Bof, j'aime pas les test aléatoire, c'est un coup à avoir un test qui foire une fois sur 50 et avec une erreur non reproductible qui au final rends plus le test instable qu'autre chose. Si ça foire, ça doit foirer à chaque fois sinon c'est pas un bon test Quelle confiance je peux encore avoir dans une jenkins tout vert si je sais que certains bugs passent 9 fois sur 10 à travers le fliet?

Problèmes: ces spécifications comportent des tas de détails subtils et parfois complexes , on a donc un langage de programmation qu'il faut apprendre à maitriser.
On peut donc s'attendre à une certaine resistance des programmeurs à adopter un tel outil (même si les codes peuvent être très concis!).

Bah d'un coté beaucoup ne veulent pas faire l'effort d'apprendre le SQL correctement et font tout en java, d'un autre plein de gens se sont lancé dans groovy et scala et ont appris à écrire des closure aspectj. Difficile de faire une prévision sur ce point selon moi

[professeur shadoko]

merci pour vos réponses.
J'ai relativement du mal à me situer par rapport à d'autre outils et encore plus de mal à trouver des compromis qui soient bien calibrés.
Je continue quand même à améliorer la chose .... même si ça fait un peu menu de restaurant chinois
Une des difficultés est de trouver des gens qui ont suffisamment de temps à consacrer pour jouer un rôle d'utilisateur pilote.
Je ferais signe quand le fruit sera mûr.

[Laurent 1973]

J'ai relativement du mal à me situer par rapport à d'autre outils et encore plus de mal à trouver des compromis qui soient bien calibrés.

Peut-être qu'aussi ton travail est de ce côté là: mieux comprend les outils actuels utilisés (junit, fitness, ...)
Une fois que tu auras une meilleur vision de comment les équipes de développement mettent en œuvre leurs tests/validations, tu pourras plus facilement te situer.

Et alors, tu pourras mettre en avant certain manque que tu as identifié et un proposition de solution via ton outil.

Bon courage

[Logan Mauzaize]

Voilà mon dilemne: je conçois et développe un framework de test (que j'espère publier en open-source en septembre)
Une première version est à la disposition des beta-testeurs ... et en réponse je n'entends qu'un grand silence!
ça m'inquiète beaucoup: serait-il possible que mon concept soit erroné et sans intérêt?
Seule demande jusqu'à présent: comparer l'outil que je propose avec JUnit.

Sur la base je vois deux problèmes, JUnit et TestNG existent depuis longtemps. Ils (JUnit en tout cas) ont beaucoup évolué au fil des ans pour proposer des features de base relativement intéressante. Bien sûr ce n'est pas sans l'apport de projets externes comme Hamcrest et le défunt Popper.

Ainsi les gens se sont pliés à ce cadre assez mature et auront du mal à bouger de leur petit siège princier, combien même le nouveau serait en velour.

Le deuxième point c'est que pour faire connaître un outil faut le diffuser. Dans la masse qu'est Internet aujourd'hui, il n'y a que le "buzz" (ou marketing viral) qui fonctionne. Seulement, je ne pense pas qu'il y ait de recette miracle pour que cela prenne.

De la chance pour toi, il existe des gens curieux et des gens compréhensifs. Va falloir trouver ceux qui combinent les deux

C'est plutot embarassant: autant essayer de comparer une girafe et un éléphant (tous les deux vivent dans la savane et ont des systèmes d'entrée/sortie comparables! ).

Comme dise les anglosaxons : It made my day

De plus je ne suis certes pas la personne la plus qualifiée pour me lancer dans une comparaison (j'ai forcément des points de vue biaisés).

C'est souvent un bon point de départ dans l'esprit. Mais les gens que j'ai cotoyé qui ont créé des choses qui sortent de l'ordinaire sont légèrement imbus d'eux-mêmes ; j'ai tendance à supposer que c'est ce qui a permi leur succès.

- Un truc embarrassant quand un programmeur veut écrire un programme de test est qu'il peut avoir l'impression de re-écrire des évidences.
Le programmeur: "bon mon code calcule un prix TTC à partir d'un prix HT ... qu'est ce qu'il faut rajouter pour tester ça? Que je donne des exemples issus de ma calculette?"
L'outil propose ici de maintenir un "zoo" de valeurs pour des données: n'y a t'il pas des valeurs particulières pour lesquelles le code de calcul ne donne pas le résultat attendu?
Pour donner un exemple si un code utilise une chaîne de caractère que se passe t'il si la chaîne est null, de longueur zero, contient des espaces, des caractères spéciaux, etc...?
L'outil permet d'écrire en un seul test un appel de méthode/constructeur avec une combinatoire de valeurs extraites des zoos. ça donne parfois un nombre important de tests
mais on découvre des bugs surprenants avec ce principe de bombardement stupide ("carpet bombing" en anglais).

Ca me fait penser aux théories et aux tests paramétrés.
Dans TestNG, il me semble qu'ils utilisent une notion de DataProvider et des marqueurs dans la classe de test pour injecter des valeurs.

- Les compte-rendus de test contiennent les résultats de TOUTES les assertions décrites avec le test (on ne s'arrête pas au premier échec).
Par ailleurs, par défaut, si un test échoue, les autres tests continuent d'être évalués ... sauf si on en décide autrement (par exemple pour des tests de matériel).
Les compte-rendus sortent complètement du dilemne échec/succès: les compte-rendus "bruts" peuvent avoir des états intermédiaire comme "warning" ou
"code non encore réalisé" (l'outil est un langage de script interprété et il permet d'écrire un test sur un code qui n'existe pas encore!).
Ensuite l'outil permet d'annoter les compte-rendus pour mémoriser la prise en compte de nouvelles exécutions des tests
(exemple: "ok ce test échoue, mais ce n'est pas véritablement un bug, c'est un comportement hors limite -ou autre chose-").

En fait, c'est toutes les notions de test, assertion et suite qu'il faut revoir. De ce côté JUnit est très médiocre car il est complètement lié à la structure du code Java : test suite (class/static), test class (instance/class), test method. Alors que les tests/assertions devraient être une arborescence complexe.

Si une assertion échoue, il est parfois inutile de faire certaines mais il peut être nécessaire de faire les suivantes. Je déteste le genre de test, tu corriges un peu point et ca explose deux lignes plus loin. Et tu recommences cette boucle 40x.

- L'outil n'est pas limité aux tests unitaires.

Ce n'est pas une mauvaise idée, la notion d'unitaire pour moi tiens plus de la mise en oeuvre que l'outil. La notion de test est bien plus abstraite que cela et un "framework" de test ne devrait pas se limiter à cela. Mais pourrait éventuellement fournir des facilitateurs pour chaque type de test.

Certes on peut utiliser un générateur de tests qui analyse une classe et génère un canevas dans lequel le programmeur n'a plus qu'à spécifier des ensembles de données et des assertions associées mais il est intéressant de constater que ce canevas génère des appels de constructeurs et puis ensuite "tube" les instances obtenues avec des programmes qui invoquent les tests de méthode sur chacune de ces instances.

Ca reste très abstrait pour moi. Ce que j'en comprend tu sépares la définition Given-Then (données - assertion) du When (scénario) ?

en fait l'outil permet d'écrire des scripts qui déroulent des comportements et permet de marquer des étapes qui généreront des compte-rendus.

Sur ce dernier point, j'ai un doute. J'ai le sentiment qu'une assertion s'auto-enregistre dans son contexte d'exécution. A voir éventuellement pour avoir une notion de section non-reportée où l'on ne garde que la description de la section plutôt que l'ensemble des assertions qui la compose mais j'avoue ne pas être fan, c'est un peu comme perdre un morceaux des logs d'une application.

Par exemple: on peut tester sur un objet le fait qu'un appel génère une NullPointerException et, dans la foulée, regarder ce qui se passe avec les codes qui sont traversés par la remontée de cette exception; la version précédente de cet outil était consacrée à des tests de mécanismes dans lesquels les interactions entre composants étaient complexes et décrites par des scénarios.

Ca me fait plutôt penser à du mocking ?

On peut également écrire des tests de montée en charge (amusants pour détecter des erreurs algorithmiques).

Ca commence à faire un outil assez ambitieux mais pourquoi pas

Notons un moins par rapport à JUnit: les tests sont exécutés dans l'ordre où ils sont définis (la version précédente essayait d'imiter le coté aléatoire par défaut de JUnit mais ça rendait les codes de scénarios incompréhensibles)

JUnit exécute les test methods (par défaut) dans l'ordre renvoyé par l'API reflection ; qui, à partir de Java 7, renvoie un ordre non prédictible (table de hashage ?). En revanche, il est possible de les faire exécuter dans l'ordre alphabétique à l'aide de @FixMethodOrder et MethodSorters.NAME_ASCENDING.
Pour moi, l'exécution des tests devraient se faire selon une logique de construction hiérachique (bloc / section). Les sections de plus haut niveau étant indépendantes les unes des autres. Dans des langages comme JS ou Ruby ca se fait très naturellement mais en Java ...

Problèmes: ces spécifications comportent des tas de détails subtils et parfois complexes , on a donc un langage de programmation qu'il faut apprendre à maitriser.
On peut donc s'attendre à une certaine resistance des programmeurs à adopter un tel outil (même si les codes peuvent être très concis!).

Pour ma part utiliser un nouveau langage de programmation serait une erreur quand on peut faire des choses très explicites et facile à manipuler avec des "DSLs". Des technos comme Groovy/Scala permettent d'écrire des DSLs très élégant.

Vos commentaires, critiques, suggestions?

Tu devrais regarder du côté des solutions JS : Jasmine, mocha et Chai sont de bonnes sources d'inspirations je pense.

Autrement au-délà de penser concept, j'embrayerai très rapidement sur l'API. Avoir de bonnes idées c'est une chose mais bien les exploiter est aussi une part importante. Surtout si on en revient au 2e problème que j'évoquais initialement !
Il faut penser aux usages simples afin que le framework soit directif. Les gens n'aiment pas de poser de questions. Mais il doit permettre ensuite de sortir assez facilement des sentiers battus et enfin une API complètement ouverte pour les utilisations avancées.

Une question importante, est-ce que l'outil repose sur la JVM ou une(d') autre(s) plateforme(s) ?

Si je devais te donner encore un conseil (et si ce n'est pas encore le cas), essaye de bien maîtriser JUnit (Runner, Rule, Theory, ParameterizedTest, Listener, etc.) et idem avec un autre framework différent. Ca te permettra d'engrenger pleins de concepts, d'idées et de limitations.

[tchize_]

même si ça fait un peu menu de restaurant chinois
....
Je ferais signe quand le fruit sera mûr.

Bon, c'est décidé, ton outil s'appelera Lychee

[professeur shadoko]

@Logan Mauzaize : un grand merci pour ta réponse très détaillée.
En gros ce que j'ai est à la base un DSL Groovy : la première version est opérationelle depuis 3 ans sur un projet orienté contrôle mécanique.
en fait la partie purement "test" n'est qu'un volet de la chose ... mais j'en fait une refonte complète (il fallait repenser cette partie que le programmeurs
n'ont pas aimé).
Plus j'approffondi plus je penche vers une approche graduelle:

- une partie qui peut s'invoquer directement depuis Java (Junit, assert, ...) et qui permet simplement d'avoir des rapports plus détaillés
des assertions cumulables et un accès au Zoo.

- une partie DSL Groovy dans laquelle les spécifications sont plus complètes/complexes et permettent de faire des tas de choses.
(ici on spécifie des DataProviders et la combinatoire des invocations se déclenche en cascade) -c'est cette partie qui pose de gros problèmes d'adoption-

- une partie "scenarios" dans lesquelles on injecte des assertions aux invocations de constructeur/méthodes et on déroule un code
si le code de script est du Groovy ça passe, par contre pour du Java pur je n'ai rien implanté et j'attends de voir.


Une autre partie (la gestion des rapports) est ouverte: je n'implante rien ... c'est aux développeurs de mettre en place
leur base de données .... les éléments sont en place mais les besoins sont trop différents selon les projets (bon c'est de l'open-source je laisse
à d'autres le soin d'enrichir )

Si un aperçu intéresse des gens ici je peux mettre en pièce jointe d'un post le manuel de la version Beta-2 (en anglais, désolé)...
mais laissez moi un petit peu de temps pour faire le ménage dans cette version beta2.
(en fait je ne sais pas si on peut mettre un document html en pièce jointe d'un post .... on verra).

Un grand merci à tous

[Logan Mauzaize]

Pour le moment ca reste assez abstrait pour moi ...

Si tu comptes publier en Open Source, pourquoi ne pas initier un espace sous Git Hub et utiliser le "README" ou les pages Git Hub pour publier la documentation ?

[professeur shadoko]

Pour le moment ca reste assez abstrait pour moi ...
Si tu comptes publier en Open Source, pourquoi ne pas initier un espace sous Git Hub et utiliser le "README" ou les pages Git Hub pour publier la documentation ?

mais c'est ce que je compte faire ! quand les codes seront propres ! (objectif publication en septembre)
Donc pour le moment je communique uniquement des avants-projets pour avoir des avis préliminaires...
quand je vois déjà les différences entre les versions 0, 01 et 02 je pense qu'il faut vraiment patienter avant de vraiment publier!
(le lychee doit mûrir -en fait le vrai nom vient du film "Moi, moche et méchant" -)

[professeur shadoko]

bon je vais essayer de donner quelques aperçus (dans 3 posts différents).

Donc 3 niveaux:
- utiisation depuis Java (par ex. tests JUnit)
- utilisation DSL Groovy
- "scenarios"

-------------------------------- NIVEAU 1: utilisation depuis Java

exemple en parasitant JUnit: on a une classe Euros

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
 
public class TztEurosDirect {
    @BeforeClass
    public static void before() {
        //ici on choisit evt. l'outil de gestion de rapport de tests
    }
 
    @AfterClass
    public static void after() {
        //on peut afficher des statistiques
        //exemple de mise ne place de résultat final
        Assert.assertEquals(SimpleFailsReporter.failsString(), 0, SimpleFailsReporter.getFails());
    }
@Test
    public void testNeutralMultiply1() {
        for(BigDecimal val : Zoo.getValuesFor(BigDecimal.class,"positives.scale2"){
            Euros gen = new Euros(val) ;
            Euros res = gen.multiply(new BigDecimal("1.000")) ;
            _codeAsserts( "neutral multiply for " + val,  Euros.class)
                    .okIf(gen.getDecimals()==2, "decimals should be 2" )
                    .okIf(gen.equals(res), "{0} equals {1}" , gen, res)
                    .okIf(gen.compareTo(res) == 0, "{0} compareTo {1} should yield 0 ",gen, res);
        }
    }
}

Pourquoi se donner cette peine?:
- on peut avoir besoin de rapports détaillés pour chaque test (dans mon projet de mécanique tous les tests sont dument enregistrés dans une base de données)
- toutes les assertions sont exécutées, les tests continuent quoiqu'il arrive (sauf si test FATAL)
- on utilise un "zoo" prédéfini de valeurs (ce sont des ensembles hiérarchiques de valeurs dans lesquelles on peut choisir des sous-ensembles - ici dans BigDecimals "positives.scale2" - )

La définition des Zoos est dans le domaine Groovy.
Exemple (fichier Integers.groovy:

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
 
_using(Integer) {
    // ....
    sizes {
            ZERO 0
            ONE 1
            NEUTRAL1 66
            PRIME2 104723
            K1 1024
            K1_PLUS 1025
            K1_MINUS 1023
            K2 2048
            K2_PLUS 2049
            K2_MINUS 2047
            K5(1024 * 5)
            // etc.  typically this values will be used to check for buffer size errors
    }
}

à suivre pour avoir un aperçu des autres niveaux ....

[professeur shadoko]

-------------- NIVEAU 2

ici on utilise des scritpts dans un DSL Groovy

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
 
_loadValues BigDecimal
 
///
TestDataList CTOR_ARGS = [
        _await(_OK, BigDecimal.positives),
        _await({_okIfCaught(NegativeValueException)}, BigDecimal.negatives.NEUTRAL),
       /// autres spécifications: bloc assertions, combinatoire valeurs
]
 
_withClass (Euros) _ctor()  {
      // amateurs de shell : on pourra remplacer _withEach par caractère |
       _test ('DECIMAL_BUILD',CTOR_ARGS) _withEach {
            _method 'asBigDecimal' _test ('SCALE2?') _xpect {
                _okIf(_result.scale() == 2, 'scale should be 2')
               // autres assertions
            }
       }
}

Dans ce cas on peut:
- specifier des tests pour des constructeurs, des methodes ou simplement l'état d'un objet
- faire des combinaisons de tests (comme dans l'exemple : on chaine des invocations de constructeurs avec des tests sur les instances produites)

Un exemple plus prosaïque:

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
 
// on crée une instance de Book de nom book
_with (book)   _method ('setRawPrice') {
    _test('CAN_I_SET_PRICE?', 22.20) _xpect {
        _okIf(book.getRawPrice().asBigDecimal() == 22.20, 'new price should be 22.20')
    }
    _test('CAN_I_SET_PRICE_AND_ROUND?', 22.223) _xpect {
        def price = book.getRawPrice().asBigDecimal()
        _okIf(price == 22.22, "new price should be 22.22 and is $price")
    }
    _test('SET_PRICE_NegativeValue', -22.223) _xpect {
       _okIfCaught(NegativeValueException)
    }
    _test('SET_PRICE_NullPointer', null) _xpect {
        _okIfCaught(NullPointerException)
    }
}

à suivre ....

[professeur shadoko]

------- NIVEAU 3

ici on fait de l'AOP en injectant des tests autour d'appels de méthodes et de constructeurs
(pas encore dispo en Beta 2)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// c'est un scenario de matériel
_scenario ('carousel storyBoard') {
      _wrap ('rotate', Carousel, Double) _xpect {
            // assertions
      }
      _wrap('open', Clamp) _xpect {
         //assertions
      }
 
     // maintenant un script Groovy qui déroule un scénario
     // rotations du Carousel, chargements, déchargements, etc...
}

à suivre ...

[professeur shadoko]

Bon .... ne pouvant pas mettre ici toute la doc de la version beta2 je mets un petit baratin (en Anglais) sur les justifications de la chose

[tchize_]

t'as pas un blog avec le projet?

[professeur shadoko]

t'as pas un blog avec le projet?

que suggères tu par là plus précisément? je suis toute ouïe ....

[tchize_]

un endroit où on pourrait consulter les debuts de doc, le code, les exemples d'utilisations
Le format forum est pas toujours le plus facile. Si c'est du projet open source googlcode ou github fournissent pas mal d'outils communautaires pour montrer ton truc
Le fofo c'est bien pour discuter mais pas pour donner les documents, on perd vite la page et faut downloader les html pour les consulter.


j'ai dit blog mais j'aurais du dire site désolé pour la confusion :p

[professeur shadoko]

oui c'est bien le dilemne: j'ai fermement l'intention de le mettre sur GitHub (conseil des gens de Groovy)
mais pour l'instant les docs et les binaires en beta2 sont livrables (ou presque) mais les sources ne sont pas suffisamment propres pour être publiées
(prévu en septembre)

[Logan Mauzaize]

Rien ne t'empêches pour le moment de créer le dépôt vide et d'alimenter les GitHub pages (https://pages.github.com/)

[Logan Mauzaize]

Si c'est du projet open source googlcode ou github fournissent pas mal d'outils communautaires pour montrer ton truc

PI, Google Code va être arrêté (http://google-opensource.blogspot.fr...ogle-code.html)