https://javaetmoi.com/tags/soa/Recent content in Soa on Java & MoiHugofrSat, 22 Jun 2013 13:29:03 +0000https://javaetmoi.com/2013/06/selenium-robuste-car-autonome/Sat, 22 Jun 2013 13:29:03 +0000http://javaetmoi.com/?p=707<p>De nos jours, l’utilisation d’un serveur d&rsquo;<strong>intégration continue</strong> pour déployer son application puis exécuter ses <strong>tests <a href="http://seleniumhq.org/">Selenium</a></strong> s’est relativement démocratisée. Néanmoins, l’investissement réalisé pour l’écriture de ces tests peut rapidement être mis à mal par le coût associé à leur maintenance. En effet, les tests d’IHM sont de nature plus <strong>instables</strong> que de simples tests unitaires. Outre des problématiques de rendu et de transversalité des fonctionnalités testées, l’une des principales difficultés réside dans la <strong>répétabilité des tests</strong>. Les <strong>données de test</strong> y jouent pour beaucoup. Cette difficulté est décuplée lorsque votre application repose sur une <strong>architecture SOA</strong> dont les services SOAP, XML ou bien REST sont hébergés par des tiers : vous n’avez aucune maitrise sur les données de l’environnement testé, ni sur sa stabilité. Des tests qui échouent régulièrement à cause de données ayant été modifiées rendent laborieuse la détection de véritables <strong>régressions</strong>. Cet article propose une solution appliquée depuis 2 ans sur une application de taille modeste (35 000 LOC pour 20 écrans).</p> <p> <figure> <picture> <img loading="lazy" decoding="async" alt="Automatisation de lexécition de tests Selenium autonomes" class="image_figure image_internal image_processed" width="833" height="563" src="https://javaetmoi.com/2013/06/selenium-robuste-car-autonome/deploiement-tests-selenium-autonomes.png" /> </picture> </figure> </p>https://javaetmoi.com/2013/02/architecture-middle-indexation-elasticsearch/Tue, 26 Feb 2013 10:35:42 +0000http://javaetmoi.com/?p=604Dans <a href="http://javaetmoi.com/2012/12/parallelisation-de-traitements-batchs-spring-batch/" title="Parallélisation de traitements batchs">un précédent billet</a>, je vous ai présenté les solutions mises en œuvre sur un projet pour paralléliser un batch d&rsquo;indexation alimentant un moteur de recherche d&rsquo;entreprise. Utilisée pour initialiser l&rsquo;index de recherche puis le resynchroniser quotidiennement, la technique d&rsquo;intégration par batch ne permet cependant pas d&rsquo;indexer les données au fil de l&rsquo;eau. Ce billet aborde précisément cet aspect. En effet, le fil de l&rsquo;eau ou le quasi temps réel fut dès le départ une exigence forte du métier. Recherches instantanées et auto-complétion révolutionnent le traditionnel formulaire de recherche mettant plusieurs secondes à renvoyer les résultats. Mais au prix de faire des recherches sur des données pouvant dater de J-1 ? Ce n&rsquo;était pas acceptable ! Un middle d&rsquo;indexation fut la réponse apportée.