Discussion :

[ray_fab]

Bonjour, j'ai un petit soucis, je travail sur une application web "pourrie". Quand plusieurs personnes se connectent à l'application sous différent poste et qu'ils fassent des actions, il peut y arriver que les les données de l'une s'échangent avec les données de l'autre, donc au final d'autres personnes se voient attribuer certaines actions alors que ce sont pas elles qui sont à l'origine, une vraie perte de données. Ce problème arrivent que lorsqu'il y a plusieurs personnes connectées. Par contre tout seul je ne peux pas reproduire le bug, en même temps en local c'est compliqué... donc je cherche à mettre en place un test unitaire me permettant de créer plusieurs Thread pour simuler le problème. Quelqu'un pourrait m'aider pour implémenter le test unitaire ou pas?
Je suis sous Spring+Hibernate+JUnit.

[Heimdal]

Tu veux faire quoi comme Unit test?
Te taper un scénario HTTP avec soumission des formulaires gestion des cookies j en passe et des meilleurs?
Si c'est le cas bon courage bien que je te conseille plutôt de te tourner vers des outils de test de charge.

Et quand je lis ça:

Par contre tout seul je ne peux pas reproduire le bug, en même temps en local c'est compliqué...

J'ai des doutes sur les tests que tu as déjà pu faire.

[tchize_]

Personnellement, je simulerais en parallèle plusieurs scénarios. Comme déjà dit, c'est très consommateur en temps à développer comme test, d'autant que c'est le genre de test qui déconne dès que tu change un peu l'interface.
Donc c'est aussi consommateur à maintenir.

Maintenant pour le problème de fond, rechercher:

• les champs "static" dans les classes (pas bien)
• les données en applicationscope dans l'application
• les donneés qui seraient stockées dans des ThreadLocal ou assimilé (vu que les thread ne sont pas lié à un utilisateur, il sont réutilisé par le conteneur)
• les états d'action sauvée dans la db (où un autre utilisateur ira le lire et finir la dite action)
• les états sauvés sur le disque entre les requetes (mais là faut vraiment être un manche pour faire ça)

D'une manière général, tout ce qui n'est pas partagé devrais rester en scope session ou request.

[ray_fab]

Bonsoir et merci pour vos réponse. En fait comme pour l'instant on ne dispose pas de tests à outils de charges ou tout simplement de Sélenium donc mon objectif est de ne pas tester les branches mais tester les Dao utilisés. Il en existe une Dao par classe persistante et elles n'ont aucune logique, les anciens développeurs utilisaient un coup SpringJDBC, un du Java SQL, un coup de la Session Hibernate super mal configurée(démarrer plusieurs transacations dans une seule méthode ou une Dao), donc vous ne pouvez pas imaginer le bordel qu'il y a dans l'application, et je me demande comment l'application fait pour tourner. Bref mon but de tester la création de plusieurs objets en les mettant dans des ThreadLocal par exemple. A vrai dire je ne sais même pas ce qu'il faut faire, donc si quelqu'un a déjà fait ce genre de choses ou un truc qui se ressemble merci de partager l'idée. Merci.

[tchize_]

Tu instancie une ou deux dixaines de threads qui effectuent une série d'action sur le DAO connues pour être "sujettes à problème", tu démarre tout ça en même temps. Au final tu test si la DB est dans l'état prévu. Idéalement tu lance ce test plusieurs fois. Je suis pas fan de ce genre de test (smoke test, parfois aléatoire) mais ça aide