Discussion :

[lalystar]

Bonjour,


Je voudrais savoir comment vous faites pour effectuer une batterie de tests unitaires sur une application bases de données ?

Quand on a des fonctions/procédures stockées qui ne manipulent pas de tables, vues... c'est très facile, il suffit de comparer les entrées et les sorties.

Mais quand on doit accéder à des données dans une table, en modifier ou supprimer d'autres comment procéder ?

J'avais pensé créer un clône de chaque table avec deux colonnes supplémentaires :
* test_id qui est l'identifiant du test unitaire.
* une colonne qui contient I, O ou IO suivant que la ligne doit se retrouver en entrée, en sortie ou les deux
Avant de lancer un test, je supprime toutes les lignes de toutes les tables. j'insère ensuite chaque ligne de chaque table les lignes I ou IO.
Je lance mon traitement.
Je compare ensuite les lignes O et IO avec celles présentes en table et je vérifie que les lignes I ont bien disparu !

C'est un peu compliqué mais je ne vois pas comment faire plus simple.

Peux être connaissez vous des outils permettant d'automatiser ce processus ?


Merci par avance pour vos réponses.

Laly.

[alex00]

Bonjour,

Une manière simple pour les TUs : extraire les résultats dans un fichier et comparer avec les résultats attendus (commande diff ou autre).
- préparer une *toute petite* base de test,
- lancer quelques tests,
- extraire les tables dans des fichiers.
vérifier une fois les fichiers, qui servent ensuite pour la non régression : diff suffit.

=> pas besoins de nouveaux schémas de bases.

Alexandre

[lalystar]

Je te remercie Alex00 pour ta réponse. Le pb est que je devrais alors utiliser des outils externes à la base alors que j'aurais tout souhaité faire de l'intérieur de la base.
En plus il faudrait que je charge dans ma base toutes les données de tous mes TU alors que je souhaite les tester en "isolation".

Je sais qu'il existe tout un ensemble d'outils permettant de faire des tests mais je ne sais pas s'il y en a un qui permettrait de répondre simplement à mon besoin.


Laly.

[ego]

Le pratiquement seul outil complet du marché et l'outil RelationalTools de Princeton Softech.
Mais c'est une usine à gaz car le pb que tu as est complexe à gérer et RelationalTools l'adresse complètement et correctement.

Si tes besoins ne sont pas énormes et que tu ne peux te payer ce formidable outil, la solution d'Alex n'est pas très différente de la tienne. Il utilise simplement des outils simples !! (le diff) pour pouvoir comparer 2 paquets de données. La solution tout en base de données est aussi valable mais le diff est plus complexe à mettre en oeuvre.

[lalystar]

Merci pour ta réponse, je vais me documenter sur cet outil.


C'est vrai que la réponse d'Alex semble plus simple, mais il faut que je gère tous les dumps, purge, export en format texte. Je vais quand même tenter, ca me semble plus simple que la mienne.


Laly.

[tipiak]

+1 avec la méthode de Alex00

pour ce qui est de l'automatisation de la procedure,

pour ma part j'utilise JUnit (sous Java)
avec une procédure de pré-requis du test ou j'attaque direct la Bd pour charger un fichier SQL contenant mon jeu de test concernant les tables concernées pour charger mon jeu d'essai

et une procédure de post-requis qui netoie la Bd après le test (le plus souvent je recharge les données qui étaient dans la base avant l'exécution du test)

et pendant l'exécution du test proprement dit je mets des points de controle en extrayant le contenu de la base que je compare avec un fichier de référence (résultat attendu comme l'explique Alex00)

par contre le coup de charger et décharger le jeu d'essai, implique de charger que ce qui est utile sinon tes tests durent des heures inutilement...


Sinon il y a DBUnit qui spécialise JUnit pour les Bds en proposant de bosser sur les tables en XML (pour les chargements et déchargement des jeux d'essais ainsi que pour les extractions pour comparer l'état des données), mais je ne l'ai jamais mis en oeuvre....

sinon le seul moyen d'éviter de recharger les jeux d'essais, c'est d'avoir une base complete de référence pour les tests unitaires
que tu charge avant de lancer une baterie de tests
mais si tu fais de l'automatisation, cela implique d'avoir une très bonne gestion de config de cette base.
ainsi que de répertorier toutes les modifs réalisées sur la BD. pour pouvoir la ramener dans son état de référence suite à l'exécution des tests (surtt quand un test echoue...)
Ce qui selon moi n'est pas adapté aux tests unitaires, qui sont le plus souvent réalisés par les développeur sur un serveur de développement (donc plusieurs personnes sur le même serveur... ca fait une gestion de config dificile...)
par contre c'est plus adaptés pour les tests d'intégration et de recette interne (avec un serveur dédié dont on maitrise parfaitement la gestion de configuration...)

[lalystar]

Bonjour,


Je te remercie pour les infos sur ces deux outils; je vais aussi voir si ca peut correspondre à mon besoin.

Je parle de tests unitaires mais en fait c'est des tests de non-régression que je souhaite mettre en place : on identifie un "bug" fonctionnel (cas qui n'avait pas été pris en compte) lors de la recette et on modifie ensuite la routine pour intégrer cette évolution du besoin. Malheureusement, souvent en faisant ca, on découvre soit de nouveaux bug fonctionnel, soit ca perturbe le fonctionnement d'une autre partie du système qui fonctionnait très bien jusqu'à présent... On est un peu dans un cauchemar sans fin en ce moment où chaque nouvelle évolution introduit de nouveaux pbs et la recette ne se termine pas

Pour éviter ca, je pensais mettre en place une batterie de tests permettant d'identifier rapidement l'impact d'une modification plutôt que de la découvrir trop tard...


Laly.

[Eowyn]

Un outil - cher mais performant - pour les tests de non-régression :
Quick Test Pro de chez Mercury.

On est en train de l'essayer, c'est assez le rêve. Mais ça prend beaucoup de temps à mettre en place - création de tous les cases.
Il semble que tu sois un peu à la bourre pour les délais donc c'est peut-être la solution pour ton problème actuel; par contre pour la suite ?

[tipiak]

donc pour la non regression effectivement ca ne se gère plus au niveau de l'Unitaire

surtout si tu fais des tests fonctionnels

comme le dit Eowyn Quick test pro permet de faire ca

mais tout ce qui est tests intégration, test de recette et non regression
je les différencie bien des TU
(car TU chez nous c'est les developpeurs qui les font)
alors que tout le reste c'est une activité a part entiere
avec (qd ca sera fini) Quick test Pro pour l'automatisation
et surtout Quality Center (de Mercury aussi) pour toute la gestion de l'activité (gestion de config, exécution des test, plan de tests ainsi que tout les reporting...)

et la pour la non regression, c'est des campagnnes de tests à part
sur un serveur dédié à ca
avec un jeu de donnés dédié aussi
et justement avec de bon outils tel que Quality Center tu peux aisément voir quels module fonctionnel est impacté par une Evolution
dans le but de sélectionner tes tests de non regression (pour faire tourner que le minimum de test)

enfin c'est des outils lourds performands et cher
donc il faut quand même avoir de quoi justifier l'achat dérriere
(genre c'est plus rentable sur une maintenance applicative que sur un forfait poncuel....)

[Franckintosh]

surtout si tu fais des tests fonctionnels

C'est quoi pour toi un test fonctionnel ?

[tipiak]

surtout si tu fais des tests fonctionnels

C'est quoi pour toi un test fonctionnel ?

c'est un test qui permet de valider un process métier
donc en gros un test ou tu simules l'utilisation par un utilisateur
genre paramétrer un module de l'application
ou établir une commande, raliser une facturation d'un certain type ...
(ca intervient essentiellement dans la phase de recette interne)
c'est le meme genre de tests que ceux fait en recette (par le client), sauf que en recette client, on travail plus sur des cas rare (ce qui nécessite d'avoir une parfaite connaissance du process métier)

par opposition à des tests plus techniques (genre fuite de mémoire, connexion multiples sur la base....)

[Franckintosh]

Ce que tu décris pour moi ça s'appelle des tests de recette (tu le dis toi même que tu fais ça en recette). Avec ou sans client présent c'est une recette que tu fais.

[tipiak]

Ce que tu décris pour moi ça s'appelle des tests de recette (tu le dis toi même que tu fais ça en recette). Avec ou sans client présent c'est une recette que tu fais.

oui c'est exactement ca c'est les tests de recette interne ou de recette client...

mais j'aime bien utiliser le terme fonctionnel car ca rappel que les objectifs sont de valider les process métiers et non valider des aspects techniques....

en fait je considerre : recette comme le nom de la phase
et fonctionnel comme un type de tests...

enfin bon après c'est qu'une question de vocabulaire, peut importe comment on appel les choses du moment qu'on est comprit de nos interlocuteurs...

[Franckintosh]

Pour moi "fonctionnel" a une connotation technique ;-). Un test fonctionnel évoque de tester des fonctions (au sens général, pas celles des langages informatique), et une fonction est déjà pour moi au délà du scope de la réponse au besoin exprimé, car pour répondre à un besoin il faut parfois plusieurs fonctions qui ne sont pas forcément visibles depuis le besoin. Tester les fonctions et tester (en fait vérifier que cela existe) la réponse au besoin sont deux choses différentes.
Ce n'est que ma perception, je pense peut être trop (comme d'habitude) et tout va bien parce qu'on parle de la même chose. En fait si on devait travailler ensemble maintenant je sais de quoi tu parles avec "test fonctionnel" ;-).

[dany_dane]

Bonjour,

J'ai exactement le même besoin sur une base de données sybase qui plus est un Infocentre alimenté quotidiennement et qui fait l'objet d'extraction pour les reportings
J'aimerai mettre en place un mécanisme de test de non regression après chaque évolution de cette base de données. C'est vrai que je n'avais pas pensé à la solution du diff sur les fichiers.

Donc concrètement avant l'évolution : je lance toutes les procédures d'alimentations et d'extraction de la base de données et les stocks dans des fichiers et je fais de même après intégrations des évolutions.
Puis je diff sur chaque fichier correspondant. Les différences qu'il pourrait y avoir seront dues aux évolutions si tant est qu'elles impactes les procédures d'alimentation/extractions deja existantes.

Est-ce donc une solution vraiment fiable ou avez vous opté pour d'autre alternatives depuis 2005

[dany_dane]

allo?