Discussion :

[kisitomomotene]

Salut à tous

J'effectue un developpement itératifs et incremental, certains modules sont donc en production et d'autre pas encore. Alors j'aimerais effectuer des tests dans l'environnement de production pour des nouveaux modules sans que cela ne pertube les modules déjà en production. Comment faites vous pour resoudre ce type de pb?
Merci

[tipiak]

Salut à tous

J'effectue un developpement itératifs et incremental, certains modules sont donc en production et d'autre pas encore. Alors j'aimerais effectuer des tests dans l'environnement de production pour des nouveaux modules sans que cela ne pertube les modules déjà en production. Comment faites vous pour resoudre ce type de pb?
Merci

je dirais: utiliser un environement de tests pour ne pas perturber la production
tu redescends les modules qui sont déja en prod sur l'env de test, tu rajoute les nouveaux de la derniere iteration:
tu tests le nouveau module, et les regressions eventuelles sur les anciens modules.
cela me parait être plus sure, imagine de tester directement en production, un nouveau module corrompt des données persistantes qui sont partagées avec un module existant celui ci devient HS, donc production down
sans compter qu'il faudra "netoyer" toute la DB de production derriere


les rares tests en prod qui sont "valables" selon moi c'est:
- tests de pré-prod : la prod n'est pas encore utilisée operationnelement (exemple d'une appli web qui n'est pas encore publiée aux utilisateurs finaux et avant le lancement commercial ....) (doncon ne peux pas vraiment appeler l'environement "Production")

- Sanity checks suite à un nouveau deployement ou modification de la production. il s'agit de tests non INTRUSIFS (pas d'impact sur la persistance)
juste pour valider le déployment (par exemple d'un module), mais cela ne valide pas le module lui meme (qui a déja été testé avant sur un env de tests), car les sanity check c'est des tests super lights (par exemple passer successivement dans toutes les pages ou fonctions d'une appli web ==> pour verifier qut tous les modules sont up and running suite au deploiment)

- le dernier, c'est des tests de type Business Availability qui ressemblent un peu aux sanity checks pour faire du monitoring END-USER de l'application
(pour prévenir ses pannes proqctivement ou pour meusurer la QoS)

dans ces deux derniers cas, les tests ne sont pas aussi pertinants qu'une reele phase de qualif sur un ENV de tests

[zaphibel]

Bonjour,
Je ne sais pas trop si je comprends bien ce que tu testes. Mais dans mon cas quand j'avais à tester des "classes" ou des modules. On créait pour le tests
des modules stub. Ce n'est autre que des fausses classes qui te fournissent le même service sans pour autant coder l'interieur. C'est un peu comme fournir des boites noires pour tes tests. Bon à priori cela est lourd mais c'est la bonne méthode. Tu pourrais faire le contraire fournir un environnement 'factis' avec
des boites noires et valider les nouveaux modules