Discussion :

[dingoth]

_skip m'ôte les mots de la bouche.

autre question : le refactoring de code java sous éclipse avec les outils d'aide au refactoring je connais. Comment est ce que je fais la même chose en PL SQL?

Si tu as un IDE qui le permet, donne-moi vite le nom, 'fin vite... pas trop non plus : le besoin de refactoring du code PL/SQL est bien moins important qu'en Java, par exemple.

[loicmidy]

Pourtant sa réponse est juste...

Le test unitaire finalement c'est quoi? Exécuter une opération et vérifier qu'elle produit les résultats attentdus dans diverses circonstances.
Il est clair que ce n'est pas junit qui les a inventé pour ne citer que lui, ça se faisait bien avant.

Tu peux tester unitairement une procédure stockée au moyen d'une autre procédure stockée de test, la deuxième déclenchant la première et testant sa valeur de retour avec un RAISE ERROR.
Tu te fais un gros script de test ainsi, c'est largement faisable...

Donc c'est entièrement possible à faire, et je suppose que ça s'est toujours fait peu importe le langage.

Dans les IDE modernes, tu as la prise en charge avec les lumières vertes comme disait dingoth et le support out-of-the-box d'un framework (nUnit, Junit, phpUnit) qui te simplifie la vie. Mais ce n'est que de l'intégration, même si c'est vrai que c'est très confortable et facilement utilisable.

d'accord, moi je connais bien JAVA et très peu le PL SQL.

cependant, ta réponse reste partielle. Le problème est plus compliqué que celà :
1 : souvent on utilise Junit avec une librairie de mock pour créer des bouchons de données : on fait comment en PL SQL? faire les mocks à la main : celà doit être possible , n'est ne pas pénible?
2: tu dis Tu te fais un gros script de test ainsi, c'est largement faisable... et celà me met la puce à l'oreille : et la maintenabilité? et la factorisation du code?
3 : lorsqu'on fait des tests unitaires en JAVA il est recommandé de faire peu de tests tapant sur la BDD (c'est pourquoi on fait des mocks) ce qui permet de faire tourner très rapidement tous les tests unitaires. A quelle vitesse tourneront ils en PL SQL?

J'ai une autre question : les développeurs JAVA essayent de faire l'effort de faire des tests unitaires propres et maintenables : on trouve de nombreux livres et retours d'expérience sur ce sujet.
est ce que les développeurs PL SQL font le même effort? Y a t il des livres sur ce sujet?

Est ce que vous avez des retours d'expériences sur le codage de tests type unitaires en PL SQL?

Pour vraiment aller au fond du sujet il faudrait coder une petite application des 2 façons (JAVA versus PL SQL) et leurs tests unitaires associés puis comparer.


en ce qui concerne le refactoring en JAVA : il y a de nombreuses options de refactoring dans eclipse. c'est expliqué par exemple dans le livre Refactoring des applications Java/J2EE de Jean-Philippe Retaillé (dans la biblio sur ce site).

[dingoth]

Oui, on fait des tests de type unitaire. En gros, comme _skip l'a dit, on crée un gros script de test, et on implémente ensuite. Cependant, implémenter la méthodologie XP en PL/SQL est plutôt difficile, car il n'existe pas d'outils comme xUnit ou Mock (d'ailleurs, le mocking n'est pas tout à fait nécessaire dans le contexte PL/SQL, si tu y réfléchis davantage).


Pourquoi voudrais-tu comparer les deux technologies ? La première chose qu'il faut savoir, c'est que leur but est différent. L'un est la création d'applications utilisables par le client, l'autre est la gestion des données utilisées par l'application. Cela revient à comparer des pommes et des poires. Les langages SQL (pas que PL/SQL) n'ont pas la prétention de vouloir prendre le rôle de Java, et inversément (quoique certains développeurs d'API pensent que ce ne seraient pas une mauvaise idée dans le sens "tout java, pas de SGBD").

En ce qui concerne le tests du côté SGBDR, pas de souci de perfs, puisqu'on reste dans la base de données. Cela me semblait... évident.


Quant à la refactorisation, tu verras que la plupart du temps, les gars qui développent pour une BDD, s'ils ont bien appris leur métier, passent parfois des jours à créer les interfaces (et uniquement les interfaces) d'accès aux données. Donc, le besoin en refactorisation est bien moins nécessaire.


Enfin, je suis content de voir combien tu sembles enthousiastes à vouloir créer un SQLUnit

[loicmidy]

[QUOTE=dingoth;4871427]
Pourquoi voudrais-tu comparer les deux technologies ? La première chose qu'il faut savoir, c'est que leur but est différent. L'un est la création d'applications utilisables par le client, l'autre est la gestion des données utilisées par l'application. Cela revient à comparer des pommes et des poires. Les langages SQL (pas que PL/SQL) n'ont pas la prétention de vouloir prendre le rôle de Java, et inversément QUOTE]

les 2 technos sont parfois en concurrence. J'ai le cas au travail (je fais de l'informatique à l'INSEE). Nous développons notamment de nombreux batchs réalisant des traitements statistiques complexes et parfois sur de gros volumes de données (i.e : 30/40 millions de lignes). Pour ces batchs j'ai 2 technos en concurrence :
PL SQL versus JAVA avec Hibernate.
Nous avons développé avec succès dans les 2 technos. Cependant pour le moment pour les batchs travaillant sur les plus gros volumes de données on est resté au PL SQL : on ne sait pas trop si avec JAVA/hibernate on aurait eu des performances acceptables (on a souvent des deadlines serrées et on n'a pas le temps de développer de 2 façons différentes puis de comparer).

Mon point de vue temporaire (je peux changer d'avis) est le suivant :
je prone la solution JAVA avec Hibernate et je cherche donc à éradiquer le PL SQL sauf si c'est justifié pour des raisons de performances.

[ego]

Attention, il faut différentier les traitements "non batch" (transactionnel) et les traitements "batch". Un modèle "pur objet" qui va bien fonctionner pour du mode transactionnel peut s'avérer totalement inopérant dans le contexte d'un traitement batch. La raison est que dans le transactionnel, on fait essentiellement des accès à un objet (on va dire une ligne dans une table) et de la navigation entre objets (requêtes "simples" avec jointure). Dans le cas du batch on est souvent amené à faire des requêtes "ensemblistes" qui sont donc "transverses" aux objets. Dans ce contexte, on a bien souvent des requêtes complexes qui tapent sur plusieurs tables avec en plus la problématique de la volumétrie.
Donc dans le cas du batch, le mapping objet/table de la partie transactionnelle de l'application n'est pas forcément adapté. Il faut donc parfois passer par un autre mapping voir faire des requêtes SQL "à la main" ou pire () faire du PL/SQL. C'est pourquoi, il y a des gens qui cherchent à faire "monter le SQL" dans la couche objet pour pouvoir faire des requêtes ensemblistes sur des objets en mémoire. On attend toujours les perfs, à ma connaissance, sur ce type de problématique.

[chaplin]

+1
Tout est dit.

[loicmidy]

Attention, il faut différentier les traitements "non batch" (transactionnel) et les traitements "batch". On attend toujours les perfs, à ma connaissance, sur ce type de problématique.

j'ai continué à réfléchir au sujet.
En fait je pense qu'il faut plutôt différentier :
d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

cordialement
loïc midy

[ego]

j'ai continué à réfléchir au sujet.
En fait je pense qu'il faut plutôt différentier :
d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

cordialement
loïc midy

Peu importe les termes mais tu as raison. Il faut adapter la solution en fonction des besoins et il est clair que pour le moment quand on a des traitements ensemblistes et que l'on peut résoudre ça en faisant des requêtes complexes en SQL, pas de soucis, c'est ça la solution. Il y a aussi la possibilité de ne pas utiliser le même schéma pour les 2 mondes et donc faire des transformations de l'un vers l'autre = dénormaliser, regrouper, trier,...
Il y avait sur jakarta un framework "SQL like" pour Java mais je ne me souviens plus du nom et je ne sais pas ce que cela vaut et si c'est aussi puissant que le SQL et certaines fonctions SQL spécifiques des SGBDR.

Ah, j'ai trouvé, c'est JXPath (donc XPath et non SQL !!) mais je ne l'ai jamais essayé

[lepinekong]

j'ai continué à réfléchir au sujet.
En fait je pense qu'il faut plutôt différentier :
d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

cordialement
loïc midy

Le monde décisionnel ou datawarehouse est effectivement très à part (pour avoir eu l'occasion d'y toucher au travers de BO ou SAPBW). Compte tenu des énormes volumes de données, il est clair qu'on ne fait plus dans le purisme du relationnel, qu'il y a de multiples redondances, bref ça ressemblerait presque à de gigantesques feuilles de tableur

A fortiori utiliser de l'ORM sur du décisionnel serait du suicide.

[B.AF]

Sans vouloir mettre de l'huile sur le feu, les univers bo sont aussi dangereux voir plus qu'un. Il n'y a pas fondamentalement de diff a opérer : il faut choisir la bonne techno et en avoir les bons usages.
L'échec de la bi est d'ailleurs le même souvent que celui de l'orm : une vision technocratique mono disciplinaire.

[SQLpro]

Citation:
Envoyé par Voir le message
il n'y a pas eu de réponse à ce post avec lequel je suis en accord.
je relance : comment on fait un test unitaire si on gère le métier dans la base de données avec par ex du PL SQL?

ah oui, bonne question ..........on fait comment les experts en base de données et en conception ?
Je sens que ça va se corser

C'est d'un simplicité enfantine.
Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
Il est alors d'une simplicité biblique de les tester unitairement...

A +

[B.AF]

C'est d'un simplicité enfantine.
Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
Il est alors d'une simplicité biblique de les tester unitairement...

A +

Enfantins si on a besoin que de crud...et ce sont des tests inutiles.
L'onjet apporte au moins le mocking, car la difficulté des tests ce n'est pas le langage mais le contexte et les données.
Mettre les tests dans la base c'est une erreur grossiére de conception, puisque dans le cas d'une application, beaucoup de données spécifiques sont dans la base. Le but du jeu d'un test, c'est bien justement d'éprouver la qualité des algorithmes métiers indépendamment de la spécialisation des données.

[Luc Orient]

... L'onjet apporte au moins le mocking ...

Et en français ça veut dire quoi ?

[dingoth]

L'objet apporte au moins le mocking, car la difficulté des tests ce n'est pas le langage maisle contexte et les données.

Mettons qu'avec Java, tu aies les instructions A, B et C. Ton contexte est l'ensemble A, B et C dans cet ordre. Ton test unitaire ne voudrait rien dire si tu testais C tout seul, mais tu le fais quand même.

En base de données, c'est pareil, on peut également écrire A, B et C sans souci et créer des tests pour chacun d'eux, et ensuite créer un test pour A, B et C ensemble. Le mocking sera moins évident pour tester B individuellement, mais avec le contexte A et C autour, tout cela deviendra cohérent. Aussi.

[B.AF]

Et en français ça veut dire quoi ?

Que j'ai un handicap à la main droite qui fait que je peux faire des fautes de frappe. Heureux ceux qui possédent les deux.

[B.AF]

Mettons qu'avec Java, tu aies les instructions A, B et C. Ton contexte est l'ensemble A, B et C dans cet ordre. Ton test unitaire ne voudrait rien dire si tu testais C tout seul, mais tu le fais quand même.

En base de données, c'est pareil, on peut également écrire A, B et C sans souci et créer des tests pour chacun d'eux, et ensuite créer un test pour A, B et C ensemble. Le mocking sera moins évident pour tester B individuellement, mais avec le contexte A et C autour, tout cela deviendra cohérent. Aussi.

Ok, ça je comprends. Dans la partie conception, si tu découpes avec une bonne granularité tes données, tu pourras obtenir le bon résultat. Mais c'est difficile d'abstraire les données. Notamment dans le cas où l'algorithme est basé sur des critères particuliers ou des règles paramétrables.

Injecter des données de test dans des procédures SQL est difficile et ça coute très cher en tests. En rapport à l'objet où le mocking est plus simple et la dépendance de données moins problèmatique-->que l'objet soit hydraté d'une base ou pas n'influe pas sur le comportement d'une méthode.

[B.AF]

D'ailleurs je voulais juste parler de Fluent Nhibernate, qui est un framework permettant de gérer les mappings au travers d'une interface fluide.

Pas qu'il soit révolutionnaire dans ce qu'il apporte, mais il met en exergue quelque chose d'intéressant de de méconnu et sous utilisé dans les ORM :
- Le contrôle de cohérence du mapping
ici
- La définition de conventions
ici

C'est à dire que si nous considérons un pattern de type unit of work avec un data access layer, le dba et le développeur peuvent se mettre d'accord de telle façon que la traduction relationnellle du modèle objet soit conforme aux exigences du dba. Cela permet donc de réunir les deux compêtences simplement.

[ego]

C'est d'un simplicité enfantine.
Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
Il est alors d'une simplicité biblique de les tester unitairement...

A +

Est-ce que ce que tu veux dire c'est que finalement, les drivers ODBC ou JDBC (en ne prenant que cela) ne servent finalement à rien. Les éditeurs ne devraient offrir que l'exécution de procédures stockées et pas d'ordres SQL ?
L'ensemble de l'industrie se serait donc trompé sur les outils mis à disposition des développeurs ?

J'ai bien compris ta position ?

[dingoth]

Non : tu extrapoles à partir de peu.

[ego]

Mais SQLPro il dit quoi lui ?