Cette semaine se tient à Bruxelles une conférence d’envergure dans le domaine du test logiciel: les Belgium Testing Days. C’est une conférence jumelle des Agile Testing Days qui se tiennent à l’automne à Berlin. Forte des succès obtenus l’an passé à Bruxelles et Berlin, l’équipe d’organisation a préparé un déroulement désormais bien rodé : 1 journée de tutoriaux, 2 journées de conférences. J’ai le plaisir de faire partie du programme de la conférence avec ma présentation Tests automatisés – Le mythe du ROI, que je délivrerai en anglais.
La conférence est placée sous le thème « QA contre Testing! Antagonisme ou Symbiose ? », un thème qui se veut provocateur, si toutefois vous faites une différence entre QA et Testing. La ligne éditoriale du programme est de questionner, et possiblement dépoussiérer, le rôle de QA, notamment s’il est perçu comme un simple guichet de passage en fin de cycle de réalisation d’un produit logiciel. On retrouve dans le programme des sessions axées sur l’expertise en ingénierie de tests, et des sessions traitant de la place des tests dans les cycles de vie du logiciel. L’intérêt de cette conférence est de rassembler à la fois une population d’agilistes et de non-agilistes, ce qui peut paraître un peu schyzophrène à première vue mais ne manque pas de sel.
Je vous invite à suivre le hashtag #btd sur Twitter pour ne rien manquer des échanges et des impressions des participants. Restez également à l’écoute du blog Xebia, je posterai des comptes-rendus des deux journées de conférence.
Les DAO (Data Access Object) ou repository des applications contiennent souvent de l’information importante sur la façon dont les données d’une base doivent être consultées. Cette information prend la forme d’une logique métier qui est encodée dans un ou plusieurs langages, souvent un langage déclaratif (SQL, HSQL, JPQL, etc.) et un langage impératif (Java, Groovy, Scala, etc.).
Tester cette logique d’accès polyglotte peut s’avérer complexe et lent car ce type de test se prète mal aux techniques classiques de mock et nécessite plutôt l’écriture de tests d’intégration qui chargent une partie du contexte réel d’exécution. Par conséquent, les tests de cette couche sont parfois délaissés, voire abandonnés.
Cet article se propose de vous montrer comment réaliser de tels tests, avec un niveau d’isolation suffisant pour la parallélisation dans un processus multithread, tout en essayant de trouver le meilleur compromis avec le temps d’exécution de chaque test. Ces tests sont présentés dans une configuration très classique utilisant Spring et JPA/Hibernate.
L’implémentation utilise une base HSQLDB et quelques bibliothèques pour faciliter l’écriture du code, en essayant de rester aussi léger que possible. Les tests sont isolés pour que vous puissiez activer l’exécution parallèle du plugin Surefire de Maven au niveau des classes de test. Vous pourrez facilement dériver l’implémentation nécessaire à isoler vos tests au niveau des méthodes si vous le souhaitez.
Pour faire simple, imaginez que sur un seul écran vous puissiez voir en un clin d’œil l’état de vos builds (succès/instabilité/échec), le nombre de tests unitaires et d’intégration agrémenté de métriques telles le nombre de lignes de code, la couverture de code et le respect des normes de codages.
Mieux qu’un long discours, nous vous proposons une courte vidéo de 3 minutes qui démontre la facilité avec laquelle vous pouvez démarrer facilement avec l’outil.
Si vous désirez en savoir plus sur le développement de ce projet, nous vous proposons une rétrospective de ces derniers mois, en partant de la genèse du projet jusqu’à son état actuel.
Comme chaque année, l’école Epita organise une semaine de conférences technologiques. Cette année la 23ème édition se déroulera du 23 au 27 Mai. Ce sera l’occasion pour les étudiants de découvrir les métiers de l’informatique et de bénéficier de retours d’expériences de professionnels.
C’est à ce titre que j’interviendrai le Mardi 24 Mai lors d’une présentation sur la dette technique. Le but sera de sensibiliser les futurs diplômés aux conséquences d’une dette non gérée sur les projets logiciels. Nous étudierons notamment les mécanismes de la dette et des bonnes pratiques pour la résorber.
Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.
Palais de justice de Paris, lundi 21 mars.
Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.
Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.
Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.
La performance a été souvent considérée comme étant le parent pauvre des applications. Afin de combler ce défaut et de détecter les éventuels points de faiblesse des applications, plusieurs outils propriétaires et open source ont vu le jour sur le marché: Compuware/Qaload, LoadRunner, OpenSTA, JMeter, etc, et notamment The Grinder. L’adoption de ce dernier fut moins évidente que celle de son homologue côté Apache, du fait de l’absence de support et d’une interface GUI pour la définition, la configuration et le paramétrage des scripts ; ce manque de l’aspect « cliquodrome » a fait croire aux utilisateurs que l’outil est à mettre uniquement dans les mains d’un développeur python, et a également conduit à en dissimuler les talents.
Le but de cet article est de donner un ensemble de guidelines pour faire un meilleur usage de l’outil.
Les tests d’intégration impliquent souvent plusieurs composants d’une architecture technique (webservices, serveurs de mail, …). Si une action s’exécute sur un composant A qui fait appel à un composant B et si la condition à vérifier dépend de la bonne exécution de B, vous êtes dans un cas d’asynchronisme. La première idée qui vient à l’esprit est d’utiliser un timer, de mettre en pause l’exécution du test pour laisser le temps à l’action de se réaliser. On comprend très vite qu’une optimisation est à portée de main, et si au lieu d’attendre un temps constant on pouvait gagner du temps si l’action s’est réalisée plus rapidement que prévu.
Nous verrons dans cet article qu’il est possible de développer des tests automatisés capables de s’adapter facilement aux contraintes d’asynchronismes et de se passer d’un blocage à temps constant grâce à l’API Awaitility.
Selenium regroupe une suite d’outils permettant de tester des applications web. Tout comme les tests unitaires, Selenium permet notamment de vérifier la non-régression d’une application et est un gage de qualité supplémentaire. Bien que la création des tests Selenium soit relativement simple, automatiser leur exécution sur un serveur d’intégration continue reste complexe à mettre en œuvre. Je vous propose une solution avec l’outil de build Maven. Disposant de nombreux plugins, comme SQL, Failsafe, Jetty et Selenium, Maven permet la mise en place d’une automatisation satisfaisante. Cette solution peut servir aussi aux tests d’intégration.
Quand on est en phase de développement et que l’on pratique le TDD, il est nécessaire de connaître certaines méthodes pour éviter la répétition, une fatigue des doigts évidente et ainsi améliorer son rendement.
Nous essayerons dans cet article de montrer l’ergonomie d’Eclipse et l’utilisation du clavier pour rendre plus courte et plus agréable une session TDD. Nous présenterons quelques plugins Eclipse et aussi un outil souvent négligé que sont les templates de codes.
Un pattern sera introduit pour faciliter l’utilisation des objet métiers et POJO dans les tests.
Enfin, nous présenterons le concept important du Continuous Unit Testing appliqué à l’IDE et indiquerons et comparerons les plugins Eclipse pour le mettre en œuvre.
Complet
Twitter
