Pratiquons le Design Pattern Delegate (ou Façade) : Démos avancées

 

Le design pattern delegate ( ou façade ) est un pattern très utilisé et facile à expliquer.

Deux démos, une simple et une seconde très avancée, vous permettent de pratiquer sereinement ce design sans difficulté.

Ainsi, les ingrédients de ce blog sont divisés en deux parties:

  • La première partie, contenant une démo simple, n'exige aucun prérequis (mis à part un peu de java 8).
  • La seconde partie, contenant une démo très avancée, nécessite de connaître un peu spring-batch et en particulier son FlatFileItemReader (retrouvez un article sur le sujet ici).

Spring-Batch (Part I) : Tester unitairement & mocker simplement. FlatFileItemReader

 

 

 

 

Comment tester unitairement et simplement les trois composants principaux de Spring-Batch: Reader, Processor, Writer?

Plus précisément comment mocker le(s) contexte(s) spring-batch pour ces trois composants?

Ce billet, sur plusieurs parties, présente quelques démos pratiques permettant de réaliser ce genre de tests unitaires (et d'intégration en prime).

Les démos sont réalisées en combinant le duo de spring: spring-batch et spring-boot.
Ce duo simplifie grandement (voire à outrance) la configuration de spring et laisse en arrière-plan beaucoup trop de complexité.

La première démo permet de réaliser un projet spring-batch avec un job contenant un seul step, le tout configuré avec java (no xml).

L'unique (step du) job consiste à charger en base (BD) les lignes d'un fichier csv nommé entreprises.csv.

Nul besoin à ce stade de processor!

Ainsi, notre job contient uniquement les composants nécessaires: un reader et un writer.

A la fin de cette première partie, nous écrirons un test TU Junit du reader.

Le seul intérêt de tester unitairement le(s) reader(s) est lorsque le métier exige un traitement personnalisé ce qui est généralement le cas! 🙁

Une fois le test TU posé et automatisé, le(s) refactoring(s) et les évolutions (agilité oblige) deviennent des opérations plus sûres.

JBehave, BDD et test d’acceptation/acceptance: Démo pratique en 20 min

blog_jbehave_bdd_titre1  blog_jbehave_jira_titre1b blog_bdd_titre2

 

Nous nous intéressons dans ce billet à l'utilisation des tests d'acceptation et le concept BDD (Behaviour Driven Development) implémenté par le framework JBehave.

Nous le pratiquons au cas particulier d'une entreprise morale ayant plusieurs établissements souhaitant ajuster automatiquement l'effectif global en fonction du turn-over effectif dans ses divers établissements (simpliste pour que le billet reste accessible).

Notre démo traite le scénario suivant avec un langage (naturel) d'acceptation proche de celui de la maîtrise d'ouvrage (MOA).

Voici donc les étapes du scénario inspiré de mon article sur design pattern observer.

Tests fonctionnels Symfony : exposer les exceptions de pages Symfony dans le rapport de test PHPUnit

Peut-être avez-vous déjà vécu cette situation où un ou plusieurs de vos tests fonctionnels échouent et le rapport d’erreur de PHPUnit n’est pas assez précis pour que vous sachiez ce qui se passe d’un seul coup d’oeil. Vous devez alors aller voir ce que fait votre test, reproduire le scénario depuis un navigateur pour enfin arriver au détail de l’exception, ou alors fouiller dans vos fichiers de logs. Cela peut vite devenir une perte de temps quand les erreurs se répètent.

Dans cet article, nous verrons comment, progressivement, nous pouvons arriver à une solution qui passe tout simplement par la capture du contenu de la page d’exception au sein de votre test et l’affichage de son contenu dans la sortie de PHPUnit.

Améliorer Behat pour Drupal avec 3 extensions : screenshot, code coverage, et watchdog

behat-logo

Behat est très puissant pour faire des tests de non régression. Comment le rendre encore plus puissant ? Avec 3 petites extensions très pratiques pour le debug :

  1. En affichant les warning rajoutés dans le watchdog automatiquement à la fin d'un test. Très pratique pour s'assurer qu'il n'y a pas d'erreur cachées pendant l'exécution des tests
  2. En rajoutant un test de couverture du code avec xdebug et phpcov pour voir si tout est bien testé
  3. En prenant un screenshot automatique de l'étape behat si elle plante, afin de pouvoir voir où est le problème sans avoir à passer par un "Then I break"

Procédure de tests de montée en charge avec gatling

gatling-logo

Gatling est un outil de test de montée en charge open-source qui permet d'écrire les scénarios de test sous forme de code élégant et concis.

À la différence de JMeter qui dispose d’une interface graphique pour la définition des scénarios de simulation et de ses paramètres, Gatling propose une API écrite en Scala. L'outil est assez élégant et permet aisément de définir des scénarios en Scala plutôt que via une interface graphique. Gatling propose une multitude de fonctionnalités dont les bases seront présentées plus loin.

Je vous présenterai dans ce billet de blog les différentes étapes à suivre afin d'implémenter un scénario de test de montée en charge écrit en Scala.