Archive

Articles taggués ‘tests’

On aime, on partage #45

Bienvenue dans la série « On aime, on partage » de Viseo Technologies ! Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.

Evènements

Getting Git Right à Paris

Apprenez comment Git décuple les possibilités pour les développeurs, rationalise le flux de développement et favorise le travail d’équipe. Ca se passe le 4 décembre après-midi et c’est Atlassian qui régale.

Agilité

Un site dédié à LeSS

Bas Vodde a annoncé la mise en ligne d’un site dédié à Large Scale Scrum (LeSS).

DotNET

Microsoft verse .NET en Open Source

Lire la suite…

En route pour la conférence internationale Software Architect à Londres

Software-Architect

La 8ème édition de la conférence « Software Architect » se déroulera à Londres du 14 au 17 octobre prochain. Anthyme et moi même auront le privilège d’y participer.

Cette année, 12 ateliers et 42 sessions sont proposés et animés par différent experts pour la compréhension des principes fondamentaux de l’architecture logicielle, idéologies et les meilleures pratiques associées.

Un mélange de séances de travaux pratiques du « monde-réel », des théories et des perspectives techniques seront proposés pour repartir avec un œil plus aguerri et des idées nouvelles sur la manière d’accomplir nos tâches avec une plus grande efficacité.

Lire la suite…

Tester le front-end JavaScript d’une application web

Introduction

La mise en place des tests automatiques permet de s’assurer du bon fonctionnement et de la conformité au cahier des charges d’une application. Beaucoup d’équipes de développement ont intégré des processus d’automatisation des tests au sein de la stratégie d’intégration continue.

Le back-end est systématiquement soumis à des suites de tests unitaires, mais qu’en est-il des tests du front-end ?

Souvent délaissé, on ne le teste que très peu, voire pas du tout. Seuls les tests manuels sont mis en place : on ouvre le navigateur et on vérifie que tout marche correctement.

Ce genre de tests ne permet pas de vérifier la majeure partie du code rédigé car ils se concentrent uniquement sur le fonctionnel et le visuel.

Mettre en place des tests du front-end structurés, par exemple en utilisant des mock objects (simulation des réponses d’une API REST du back-end), permet également de développer l’interface graphique sans avoir à attendre un back-end fonctionnel : c’est plus efficient.

Enfin, avec l’arrivée des nouveaux frameworks de front-end full-javascript (Angular, Backbone, Ember, et j’en passe), on crée des modules réutilisables, qu’il convient de valider et de tester afin de mesurer leur stabilité, et donc leur ré-utilisabilité dans d’autres projets… tout comme on le ferait pour un module Node.js !

Lire la suite…

On aime, on partage #20

Bienvenue dans la série « On aime, on partage » d’Objet Direct !
Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.
 
 
 
 

Java

“Oh Lord, won’t you buy me a Mercedes benz” (or RIP GlassFish)

Un rapide aperçu de l’avenir des serveurs d’application Java chez Oracle, en particulier GlassFish

http://antoniogoncalves.org/2013/11/06/oh-lord-wont-you-buy-me-a-mercedes-benz-or-rip-glassfish/
 
 

Agilité

Feedback sur LeanKanban France 2013 en mode « Gonzo Journalism »

Voici un retour très ludique sur LeanKanban France 2013 de @ndeverge, qui s’est déroulé le 3 et 4 octobre dernier.

Bonne Lecture :-)

http://www.ekito.fr/people/?p=3478

 
 

Le management français toujours très rigide

Autocratique ? Rigide ? le management français vu par plusieurs études, reste trop frileux vis à vis de l’agilité et des changements de postures qu’elle impose.

http://m.rse-magazine.com/Le-management-a-la-Francaise-encore-un-peu-psychorigide_a258.html
 
 

Testabilité

Avez vous déjà fait tout ces types de tests ?

Une impressionnante liste de tests que l’on peut (doit ?) faire sur un projet informatique

www.guru99.com/types-of-software-testing.html
 
 

Merci à nos contributeurs de la semaine : Maxime Bonnet et Jamel Ghechoua!

Categories: On aime, on partage Tags: , ,

Devoxx 2013 – Les quickies d’OD

Du 27 au 29 Mars, Objet Direct était présent à Devoxx France à Paris. C’est un rassemblement de développeurs / décideurs du monde Java principalement, mais on peut aussi y croiser des passionnés de JavaScript, Ruby et des différents langages qui fonctionnent dans la JVM (Ceylon, Scala, Groovy …)

Plusieurs formats de conférences sont accessibles pendant les trois jours. Le format classique, des conférences d’une heure, des « labs » (trois heures pour découvrir un outil, un framework, un langage), mais aussi des « quickies » , des présentations au format court de 15 minutes, pendant la pause déjeuner.

Trois consultants de Objet Direct ont été sélectionnés pour présenter des quickies, voici leurs retours.

Lire la suite…

Juniors ! Plus d’excuses pour ne pas écrire des tests.

J’ai beaucoup lu sur les avantages des tests automatiques, j’ai même écrit quelques tests unitaires pendant mon « spare-time », afin de voir de quoi il s’agit. Mais, ils n’étaient pas suffisants pour répondre à cette question — que fort probablement vous vous êtes posés — : pourquoi devrais-je perdre du temps à écrire des tests et retaper certaines logiques ?!

Personnellement, « I saw the light » et j’ai trouvé ma réponse après avoir écrit des tests unitaires dans le cadre d’un projet concret.

Lire la suite…

Categories: Java EE Tags:

Lyon JUG : performances!

Pour les fêtes de fin d’année, offrez un petit bench à votre application préférée :Lyon JUG une  soirée dédiée au Lyon JUG, mardi 21 décembre, animée par Claude Falguière.
C’est désormais une tradition gravée dans le marbre : préparez-vous avec l’interview teasing par les JDuchess.

Inscription et informations pratiques, as usual, sur la page officielle du Lyon JUG.
A mardi!

Categories: Actualités, Outillage Tags: , ,

Agile France 2010

Agile France 2010

J’ai assisté ces derniers jours à la conférence Agile France 2010, 5ème édition de ce qui s’appelait « XP days » ces dernières années. Je vous livre ici mon ressenti sur ces deux jours de conférence que je considère comme un retour sur la situation de l’agilité en 2009. Pour situer un peu le contexte, j’y ai assisté en tant que Scrum Master/Développeur mais aussi dans une perspective future de coaching/accompagnement vers l’agilité.

La première chose marquante pour moi : sur plus de 60 présentations … à priori une seule a pour sujet principal Scrum et elle est annotée ‘Débutant’ ! Je me pose donc la question du pourquoi : est-ce que Scrum est déjà en cours d’abandon (les problèmes de certification lui ont certes causé du tort mais tout de même !) ? Devenu trop ‘mainstream’ pour qu’on ait encore des choses à dire dessus ? … Si vous avez des éléments de réponse, je suis preneur !

De même, les sessions sur la « vente » de l’agilité ont été plutôt rares (2 seulement) : l’agilité rentre dans les mœurs et il est devenu moins nécessaire de convaincre ?

En revanche le Lean s’est taillé la part du lion dans la catégorie ‘les bases des méthodologies’ pour une petite dizaine de présentations, associé à la bonne dizaine de sessions sur la transition de l’organisation vers l’agilité. C’est, il me semble, un point important à retenir : l’agilité commence à dépasser le cadre de l’équipe de développement pour s’installer dans les DSI en premier lieu et s’immisce doucement vers l’organisation de l’entreprise toute entière. Cela se fait principalement sur le constat suivant : les développements deviennent performants avec Scrum mais l’entreprise n’arrive pas à digérer cette performance, le lead time global peut difficilement changer si l’organisation n’est pas adaptée.

XP aussi est beaucoup ressorti, j’interpréterais cela de différentes façons : en premier lieu, la conférence s’est appelée XP Days pendant 4 ans, même si elle n’était pas exclusivement destinée à XP. Et puis c’est tout de même sur ces pratiques (plus que sur toute autre méthodologie … tiens, un élément de réponse :-) ) que les principes de l’agilité dans le monde du développement logiciel DOIVENT se reposer. L’accent a été mis sur les tests automatisés (10% des sessions) avec notamment le TDD qui commence à percer tout doucement. Et bien que ces pratiques soient globalement comprises elles restent toujours très peu mises en place.

Le dernier point que j’ai pu ressentir, certainement le plus important (pour moi étant donné mon profil mais aussi pour la réussite sur le long terme de projets de développement), c’est l’accent mis sur l’équipe, ses interactions et l’amélioration de la communication, le tout à la limite du développement personnel. Mais aussi un retour qui émerge : l’agilité à plein régime c’est exténuant et tout le monde ne supporte pas la transparence et le courage requis ! Le tout couronné d’une keynote d’Esther Derby sur l’alchimie équipe/management où comment se faire confiance réciproquement.

Ce fut une expérience instructive qui m’a permis de prendre un peu de recul et d’entrevoir de nombreux pans de l’agilité, et tout cela dans un environnement propice aux échanges dans un coin de verdure en bordure du bois de Vincennes. Un grand merci aux organisateurs !

soapUI : tests de charge de Web Services

Je continue mon tutorial sur soapUI. Voyons cette fois-ci comment utiliser soapUI pour réaliser des tests de charge.

Il faut ajouter un nouveau test de charge sur le TestCase voulu.
Note: il faut savoir que le test de charge va lancer tous les tests en parallèle, donc il ne faut pas qu’il y a de dépendance entre les services du TestCase, car ceci pourrait fausser vos résultats.

clip_image002

Une fenêtre s’ouvre, il est possible de choisir la stratégie de test et de la configurer.
A savoir : la durée du test, le nombre de threads à utiliser, le délai (aléatoire ou non) entre chaque nouvelle requête, etc.

clip_image004

Sur cette image on peut se rendre compte qu’un service qui renvoie une stacktrace d’exception est couteuse en temps et en données.


Le tableau de résultat affiche : le temps de réponse min max moyen, le nombre de requêtes totales lancées lors du test, le total de données transférées, le nombre d’erreur.

De plus, la console de log en dessous permet d’avoir des détails sur les tests déroulés, comme l’heure de début et de fin du test, les éventuelles erreurs, etc …

soapUI : pré-remplir les champs d’une requête

Suite de mon tutorial sur soapUI, voyons cette fois-ci comment pré-remplir certains champs d’une requête. Par exemple, un login et un password nécessaire pour se connecter.

Si vous avez une série de requêtes dans votre Test case, il est préférable de créer un script qui se chargera de vous pré-remplir ces champs plutôt que de le faire à la main 😉

Il faut créer un nouveau « step » nommé ‘Groovy Script’.

clip_image002

Voici un exemple de code qui pré-rempli les champs ‘login’ et ‘password’. Ces valeurs doivent être déclarées et initialisées dans l’onglet « Custom Properties » du projet (il s’affiche en cliquant sur le nom du projet).

image

Entrez ensuite le code du script :

image

Un petit Copier-(Réfléchir*)-Coller du code suivant simplifiera le travail !             (* © F.D.)

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
//variables definitions
def login = '${#Project#login}'
def password = '${#Project#password}'

//Retrieves all TestSteps of the current testCase
log.info("* " + testRunner.testCase.name )
def testStepList = testRunner.testCase.getTestStepList()

testStepList.each{currentTestStep->
    if (currentTestStep.name != "Inits fields") { //ici liste des steps que le script ne doit pas modifier
        log.info(" \\-- " + currentTestStep.name )
        def holder = groovyUtils.getXmlHolder( currentTestStep.name+"#Request" )
        log.info(" " + 'holder' )
        holder.namespaces["ns"] = "http://schemas.xmlsoap.org/soap/envelope/"

        //Inits values of the current testStep
        log.info(" " + 'login' )
        holder.setNodeValue("//ns:Body/*/login", login)
        log.info(" " + 'password' )
        holder.setNodeValue("//ns:Body/*/password", password)

        //Updates the change
        holder.updateProperty()
    }
}
'Script OK'

Voici la requête une fois le script exécuté :

image

Note : pour éviter de faire un copier-coller du code à chaque Test case, il est possible de cloner ce « step » et le déplacer dans un autre Test case :-)