http://blog.xebia.fr/2010/04/19/revue-de-presse-xebia-155/ J2EE, Agilité et SOA Fri, 10 Feb 2012 09:50:25 +0000 hourly 1 http://wordpress.org/?v= http://blog.xebia.fr/2010/04/19/revue-de-presse-xebia-155/#comment-70169 Revue de Presse Xebia | Blog Xebia France Wed, 17 Aug 2011 13:12:38 +0000 http://blog.xebia.fr/?p=4418#comment-70169 [...] la plateforme qui fait sien le slogan de RabbitMQ: Cloud Messaging that just works. Rappelons que RabbitMQ a été racheté par SpringSource/VMware il y a un an et demi et cette nouvelle annonce valide finalement leur [...] [...] la plateforme qui fait sien le slogan de RabbitMQ: Cloud Messaging that just works. Rappelons que RabbitMQ a été racheté par SpringSource/VMware il y a un an et demi et cette nouvelle annonce valide finalement leur [...]

]]> http://blog.xebia.fr/2010/04/19/revue-de-presse-xebia-155/#comment-24818 philippe voncken Thu, 22 Apr 2010 15:14:21 +0000 http://blog.xebia.fr/?p=4418#comment-24818 @Nicola frank Dans l'article il parle de Selenium-IDE qui n'est pas maintenable effectivement. Par contre avec Selenium-RC il est possible de créer un socle de tests fonctionnels automatisés performant et maintenable. @Nicola frank
Dans l’article il parle de Selenium-IDE qui n’est pas maintenable effectivement. Par contre avec Selenium-RC il est possible de créer un socle de tests fonctionnels automatisés performant et maintenable.

]]> http://blog.xebia.fr/2010/04/19/revue-de-presse-xebia-155/#comment-24604 nicolas frank Tue, 20 Apr 2010 21:49:54 +0000 http://blog.xebia.fr/?p=4418#comment-24604 Pour les tests d'interfaces, moi je reste un fan de htmlUnit. On l'utilise sur nos projets depuis bientôt 7 ans (au départ c'était httpUnit, mais c'est quasi pareil) et ce sont des plateformes financières complexes dont les écrans évoluent très régulièrement. L'api est simple, et en factorisant un peu les choses, les tests restent très simples à maintenir. Idéalement vous les inscrivez dans la 'Definition of Done' de la story. Vous les intégrez également à votre intégration continue, un peu de discipline et normalement ça roule :)... Quel confort face aux régressions, car au final c'est bien l'interface qu'utilise le client, alors les fonctionnalités qui ne marchent pas, alors que "tous mes tests unitaires passent", à cause d'un javascript bugué, nous on connait pas. Un bon truc aussi pour vérifier que votre site tourne toujours en production et dans des performances équivalentes, c'est d'isoler un test de parcours idempotent et de le faire jouer en continue vers la prod. Si le serveur n'est plus accessible ou si les perfs diminue au delà d'un seuil défini vous êtes alerté (l'équipe de prod adore, nous aussi !). On a essayé sélénium y a quelques années, je confirme, idéale pour du one-shot (et encore on avait des pages "non prédictible" d'attente, et là ça se corse rapidement), non maintenable dans la durée... les langages de script sont en fait de mauvais candidats pour les tests d'applications qui changent souvent selon moi. Dans la série automatisation des navigations, un de vos concurrents en 4 lettres nous avaient vendu les tests de montée en charge automatisés avec OpenSta, c'était il y a 5 ans... ils ont jamais réussi ! Pour les tests d’interfaces, moi je reste un fan de htmlUnit. On l’utilise sur nos projets depuis bientôt 7 ans (au départ c’était httpUnit, mais c’est quasi pareil) et ce sont des plateformes financières complexes dont les écrans évoluent très régulièrement. L’api est simple, et en factorisant un peu les choses, les tests restent très simples à maintenir. Idéalement vous les inscrivez dans la ‘Definition of Done’ de la story. Vous les intégrez également à votre intégration continue, un peu de discipline et normalement ça roule … Quel confort face aux régressions, car au final c’est bien l’interface qu’utilise le client, alors les fonctionnalités qui ne marchent pas, alors que « tous mes tests unitaires passent », à cause d’un javascript bugué, nous on connait pas.
Un bon truc aussi pour vérifier que votre site tourne toujours en production et dans des performances équivalentes, c’est d’isoler un test de parcours idempotent et de le faire jouer en continue vers la prod. Si le serveur n’est plus accessible ou si les perfs diminue au delà d’un seuil défini vous êtes alerté (l’équipe de prod adore, nous aussi !).
On a essayé sélénium y a quelques années, je confirme, idéale pour du one-shot (et encore on avait des pages « non prédictible » d’attente, et là ça se corse rapidement), non maintenable dans la durée… les langages de script sont en fait de mauvais candidats pour les tests d’applications qui changent souvent selon moi.
Dans la série automatisation des navigations, un de vos concurrents en 4 lettres nous avaient vendu les tests de montée en charge automatisés avec OpenSta, c’était il y a 5 ans… ils ont jamais réussi !

]]>