Tests de performances avec Visual Studio Tester (Partie 2)

       Visual_StudioTester

Visual Studio Tester

Que se soit les petites ou grandes entreprises, la plupart des interrogations sur la fiabilité d’un SI est très lié à son architecture / Infrastructure. Les tests les plus pertinents sont les charges de performances, les tests de rupture, … ainsi que sur les KPI / indicateurs de performance des sites (la génération de trafic et taux de transformation/Conversion).

Dans la première partie, je vous ai proposé de voir les différents points :

  • La création d’un test Performance Web
  • Les enchaînes des scénarios
  • L’extraction « Custom » JSON (fonctionnalité manquante)
  • Liens utiles

Nous allons aborder dans la 2ème partie les points suivants :

  • Import de fichiers de Datasource
  • Les LoadTests permettant de simuler une charge ou déterminer le seuil de rupture…
  • Liens utiles

 

Tests de performance avec Visual Studio Tester (Partie 1)

       Visual_StudioTester

De nos jours, de nombreuses entreprises cherchent à déterminer la qualité et l’endurance de leurs applications. Que ce soit des Webservices, des sites internet, la stabilité de leurs infrastructures…

Je vous propose de voir dans la première partie :

  • La création d’un test Performance Web
  • Les enchaînes des scénarios
  • L’extraction « Custom » JSON (fonctionnalité manquante)
  • Liens utiles

MageUnit : écrire des tests unitaires Magento en toute simplicité

magento_logo

Magento est solution e-commerce puissante dont la réputation n’est plus à faire. Lorsqu’il s’agit d’écrire des tests unitaires automatisés, on ne peut toutefois pas dire que Magento nous facilite la tâche. Le code natif est souvent peu testable. Les principales raisons : la grande complexité de bon nombre de méthodes et souvent l’impossibilité d’injecter des doublures de test au sein de celles-ci. Si le développeur, en écrivant du nouveau code, peut en maîtriser sa complexité, il est plus difficile pour lui de se défaire du problème d’injection de dépendances qui se posera lors de tout appel à du code natif Magento. Heureusement il existe des solutions à ce problème et MageUnit est l’une d’entre elles.

Améliorez les performances: Parallel processing with Camel & Spring (Partie 1/2)

Ce billet s’inscrit dans la catégorie optimisation des performances.

Il se fixe comme objectif d’illustrer avec démo détaillée comment améliorer significativement les performances de nos projets.

Et cela sans se lancer dans l’aventure d’écrire des kilomètres de code lourd de gestion du ‘parallel processing’ car nous allons laisser la puissance du framework Camel opérer.

Sachez néanmoins que de nombreux problèmes de mauvaise performance peuvent être traités sans recours aux implémentations complexes de parallélisme.

Voici deux situations où il faudrait réfléchir sur l’apport du parallélisme :

– Si les tâches ou opérations ne prennent que très peu de temps (échelle quelque sec). La gestion/monitoring des threads devient coûteux.

– Si les ressources mémoire, CPU et IO sont déjà fortement utilisées; sachez que le parallélisme consomme davantage de ressources.

Le billet veut s’inspirer (librement) des deux étapes décrites dans la démo du chapitre 10 du livre « Camel in action ».

L’essentiel du code source est fourni ici.

Sachez néanmoins que le code présenté ci-après a été largement adapté et pour certaines parties complètement réécrits.

En effet, comme j’utilise Spring, toutes les parties de code sont adaptées ou réécrites en fonction.

En particulier j’utilise l’implémentation spring ThreadPoolTaskExecutor de l’interface TaskExecutor à la place de la méthode statique de Executors de java.

Le billet est organisée en deux parties:

– La première partie permet d’exécuter en séquentiel notre démo,

– La seconde permet adapte la première partie pour une exécution parallèle.

Nous donnons quelques indications sur le temps d’exécution de chacune des parties.

Avec les bons paramètres nous pouvons diviser par quatre le temps d’exécution voire plus.

Le framework Camel offre avec son java DSL des fonctions permettant d’obtenir simplement de meilleurs performances en parallélisant les tâches.

Comme d’habitude nous le combinons avec le framework Spring v3+ car peut-on faire autrement?

Dans le domaine de performance, il est utile d’identifier les deux limites: CPU-bound et IO-bound.

Distinguer ces deux limites permet d’identifier le bon choix pour améliorer les performances.

En guise de conclusion, dans le domaine d’exécution parallèle, Camel simplifie grandement la vie des développeurs.

Néanmoins, il leur reste la responsabilité de la cohésion des données.

Passons à la mise en pratique.

Spring parallel processing. Exécution parallèle avec Spring

Ce billet tente de démystifier l’utilisation en java5+ des exécutions en parallèle des tâches (parallel processing) en s’appuyant sur les classes de Spring qui masquent les difficultés du parallélisme en java.

Les machines de nos jours viennent avec plusieurs processeurs: des multi-core (quatre, huit ou plusieurs centaines cœurs).

Or la puissance de ces ressources n’est pas constamment utilisée.

L’exécution parallèle autorise des calculs parallèles qui consomment ces ressources pour améliorer les performances.

Mais c’est comme tout, le parallélisme ça se mérite. Même si c’est un petit chouia difficile!

En réalité, la difficulté n’est pas dans la mise en place technique mais réside dans la gestion de la cohésion des données.

Techniquement, c’est le développeur qui doit réaliser les calculs parallèles.

C’est sûr, demain apparaîtront côté JVM les méthodes de traitement du parallélisme comme c’était le cas de la gestion mémoire avec le garbage collector ou récemment la gestion des descripteurs de fichier avec try/catch en java7.

Java 8+ nous proposera (peut-être) de faire le calcul paralléle à notre place (nous développeurs).

Ce qui reste au développeur c’est de décrire les traitements atomiques (comme l’atomicité dans les transactions), et à partir de là c’est la JVM qui mène le traitement global parallélisé efficacement en fonction des ressources disponibles.

Bel enjeu de demain.

Signalons que nous n’utilisons pas directement la classe Executors de java qui offre des méthodes statiques pour instancier un Executor ou un ExecutorService.

A la place nous utiliserons les classes de Spring.

La démo ci-après est faite en java7 et spring 3.

Passons à la mise en pratique.

Intégration à Eclipse d’outils d’assurance qualité pour PHP

L’écosystème PHP regorge d’outils permettant d’augmenter sensiblement la qualité du code produit par les équipes de développement. On peut noter les travaux avancés de Sebastian Bergmann et plus généralement des contributeurs de la PHP Quality Assurance Toolchain qui fournissent à la communauté un outillage précieux.

Ce billet explore les outils les plus couramment utilisés lors d’une analyse du code PHP. Souvent plébiscités dans un cycle d’intégration continue ; ils sont rarement intégrés à l’environnement de développement : lancement manuel via un terminal, pre-hook sur un serveur de versionning. L’objectif est ici d’augmenter l’interactivité de ces outils avec les développeurs et de leur permettre d’aborder des méthodologies comme le Test Driven Development (TDD) plus sereinement.

Mocking avec le framework « Moq » en .NET

Lorsque l’on doit écrire des tests unitaires, il est souvent très pratique de pouvoir simuler le comportement de certains objets pour travailler dans un contexte isolé.

Par exemple simuler un « repository » d’objets habituellement liés à la base de données avec un « repository » factice ne retournant qu’un objet bien défini ou encore simuler les réponses d’un service Web sans même devoir le contacter.

Il est aussi important d’utiliser des objets factices pour conserver le caractère de répétabilité d’un test (une propriété de date ou un capteur de température devant rester figés pour obtenir les mêmes résultats en sortie et donc la validation du test).

[Paris JUG] Soirée spéciale Tests

Le 11 janvier 2011 a eu lieu le premier JUG de 2011, ayant comme thème: les Tests.
La soirée était animée par David Gageot, auteur du blog Java Bien!.

Lors de nos développements, nous avons tous été confrontés à écrire des tests. Un bon développeur doit écrire des tests fonctionnels et/ou unitaires de façon régulière. Mais s’il y a beaucoup de tests, le build prend plus de temps. Du coup, nous perdons du temps sur la suite du développement.

La question est: Comment faire des tests rapides et efficaces ?

AGILE & MORE EFFICIENT : Test JUnit, EasyMock & Spring

Ce billet aborde l’aspect purement technique de mise en oeuvre de l’agilité dans le développement d’applications robustes.
Il s’inscrit dans la continuité du séminaire de Netapsys sur le thème « Agile & more efficient ».
Il présente les tests JUnit 4.x et EasyMock sous Spring afin de concrétiser « être agile ».
EasyMock permet de simuler l’accès aux fonctionnalités des couches applicatives, par exemple la couche DAO.
Un des piliers de l’agilité est TDD (Test Driven Development).
Le TDD est une approche évolutive de réalisation de projets basés sur les tests avant même de produire du code effectif.
TDD combine le TFD (Test First development) et le refactoring afin d’arriver à affiner / définir les spécifications.
Easymock et JUnit constituent donc les briques afin de réaliser le TDD via les tests unitaires et d’intégration.
En fait, les tests unitaires sont faciles à mettre en place mais les tests d’intégration restent encore difficiles.
Et le coût de réaliser les tests d’intégration est pesant.
Et EasyMock permet la mise en place des tests sans pour autant avoir développé une ligne de code d’implémentation des couches applicatives.
Tous ces aspects vont être explicités ci-dessous.