Gestion des jeux de données

Zoé
Messages : 126
Inscription : lun. sept. 19, 2016 2:24 am

Gestion des jeux de données

Message par Zoé »

Bonjour,

Lors d'un projet Squash TA-TM, nous avons mis en place une architecture (que nous pensons pouvoir améliorer), à savoir :

1 fichier TA -> 1 classe java + 1 fichier SQL de setup + 1 fichier SQL de teardown.

Dans le SETUP du fichier TA, nous lançons le fichier SQL de setup. Même principe pour la phase de teardown. Entre les deux, la phase de test, avec la macro EXECUTE_SELENIUM2.

Tout fonctionne, mais niveau maintenance, ce n'est pas très pratique : il faut venir modifier chaque fichier SQL. Notre patrimoine de test est déjà riche de 400 automates, et ce nombre va aller croissant...
Y a-t-il un moyen de regrouper les jeux de données, dans un fichier CSV par exemple, et de simplement spécifier la ligne concernée dans le fichier TA ? Nous savons le faire en Java, mais il serait plus idiomatique de le faire dans le script TA si cela est possible.

Merci d'avance pour vos retours.
Karim Drifi
Messages : 119
Inscription : lun. nov. 30, 2015 2:45 pm

Gestion des jeux de données

Message par Karim Drifi »

Bonjour,

Je ne suis pas certain de bien comprendre exactement vôtre problématique.
Ce qui vous pose pose problème c'est le nombre de fichiers sql à maintenir ?

Il n'y a pas à ma connaissance de moyen directement de choisir la partie d'un fichier de resources dans un script ta, cependant si vous me précisez votre questionnement je peux sans doutes apporter un moyen de contournement pour améliorer la maintenabilité de votre patrimoine car je rencontre fréquemment ce genre de problématiques.

Bien cordialement,

Karim Drifi
Zoé
Messages : 126
Inscription : lun. sept. 19, 2016 2:24 am

Gestion des jeux de données

Message par Zoé »

Bonjour Karim,

Et merci pour cette vague de réponses :)
Nous avons l'habitude, avec UFT, de gérer nos jeux de données dans des fichiers CSV. Nous aimerions pouvoir faire de même avec Squash TA afin de clairement séparer les scripts et les jeux de données, avec une syntaxe moins lourde qu'un fichier SQL. Cela est-il possible ?
Si non, je veux bien connaître des solutions de contournement pour les projets comme celui-là, qui contiennent beaucoup de scénarios et de jeux de données.
Karim Drifi
Messages : 119
Inscription : lun. nov. 30, 2015 2:45 pm

Gestion des jeux de données

Message par Karim Drifi »

Je ne peux donc que vous proposer un moyen de contournement en plusieurs étapes :
- remplacer les données en dur dans vos fichiers sql par des clés au format ${ma.cle.toto.tutu},
- créer un fichier ".properties" dans vos resources regroupant l'ensemble des clés qui se trouvent dans tout vos fichiers sql,
- enfin (le plus délicat) : écrire un script sur-mesure permettant de mapper les données de votre fichier csv sur votre fichier ".properties".

Il m'arrive de faire ce genre de manip afin de ne pas trop "éclater" mes jeux de données dans des dizaines de fichiers sql (ou autres).
Pour l'écriture du script je recommande d'expérience plusieurs choses :
- inclure le script dans votre répo de suivi de version (git, mercurial, svn...)
- si les postes de développement sont sur du microsoft : écrire le script en bash et installer "git bash" sur les postes microsoft. Cela permet d'avoir un unique script qui fonctionne sur le serveur jenkins (exécution en "pre build step" ainsi qu'en local car git bash fournit un très grand nombre de commandes d'un bash.

A noter que je suis en train de pousser l'évolution suivante : création d'un fichier de configuration global (à la racine du projet) qui override toutes les propriétés qu'on lui fournit et qu'il retrouve dans un fichier properties. Le fichier global pourrait avoir deux formats : ".properties" et ".json". Le scond format permettant de structurer de manière lisible toutes les données.

Cordialement,

Karim Drifi.
Karim Drifi
Messages : 119
Inscription : lun. nov. 30, 2015 2:45 pm

Gestion des jeux de données

Message par Karim Drifi »

PS : merci pour vos multiples contributions à ce forum :). Je voudrais avoir plus de temps à y consacrer de mon côté...
Répondre

Revenir à « SKF »