Tests

Archi & techno

GWT & les tests, épisode 2

Dans le précédent article, nous avons démontré qu'il n'était pas si facile de faire des tests avec GWT car : La classe de test de base, GWTTestCase est trop restrictive (impossible d'utiliser des outils de tests), et est source de lenteurs Le mock de composants GWT requiert l'utilisation d'interfaces intermédiaires plutôt que des classes de composants, ce qui induit un gros travail de refactoring sur les projets existants Nous avons donc mis en place une solution alternative...

Lire la suite
Archi & techno

GWT & les tests, épisode 1

GWT est un framework permettant de créer une interface Web riche en Java plutôt qu'en HTML et Javascript. La programmation de l'interface ressemble beaucoup à du Swing : new Panel(), new Button(), add ClickListener... C'est une approche assez séduisante : pas besoin de connaître un nouveau langage, possibilité de réutiliser les outils que l'on utilise en Java... De plus, comme tout est en Java (même la partie vue du modèle MVC!), on devrait donc pouvoir faire des tests sur l'IHM. Essayons donc.

Lire la suite
Archi & techno

Combien de temps doit prendre un build Maven ?

Suite à mon précédent post, La meilleure façon de rater son projet grâce à Maven2, un collègue m'a décrit la situation suivante "Une pratique sur notre projet est de lancer un build maven -mvn clean install- sur son poste local avant de faire un commit. Cette commande est super longue, et les développeurs disent 'c'est normal c'est maven qui est long', ça doit prendre combien de temps un build Maven ?".

Lire la suite
Évènement

ALT.NET et TDD

"- Mais pour ton application pourquoi tu ne mettrais pas des tests unitaires automatiques ? - Non, Trop cher ! Trop compliqué ! - Ah bon, t’es sûr ??..." Un échange qui vous semble familier ? Si oui, bonne nouvelle, mercredi 25 Mars se déroulera une réunion du groupe ALT.NET France pour découvrir (ou approfondir) comment le développement piloté par les tests (TDD) permet de réaliser une application testée, donc maintenable et évolutive. Ce gain finance de loin le temps consacré à l'écriture des tests, et…

Lire la suite
Archi & techno

La stratégie de test d’une architecture REST (2/3) – Test d’intégration

Cet article est le deuxième d’une série de 3 articles traitant de la stratégie de test d’une architecture REST. Il fait suite au billet sur le test unitaire d’une ressource REST. Pour rappel nous allons, par l’exemple, mettre en pace une stratégie de test sur un code d’exposition de web services REST en Java. L'exemple de code se basera sur le framework REST Jersey, implémentation de référence de Sun de la JSR-311 déjà présentée dans un précédent article . Le but de ces trois articles…

Lire la suite
Archi & techno

La stratégie de test d’une architecture REST (1/3) – Test unitaire d’une ressource

Cet article est le premier d’une série de 3 articles traitant de la stratégie de test d’une architecture REST. Il fait suite au billet sur les types de test utilisés sur un projet Agile. Par l'exemple, nous allons mettre en place une stratégie de tests sur un code d'exposition de web services REST en Java. L'exemple de code se basera sur le framework REST Jersey, RI de Sun de la JSR-311 déjà présenté dans un précédent article. Le but de ces trois articles est de présenter…

Lire la suite
Méthode

Quels sont les types de tests que l’on utilise sur un projet agile ?

Constat Typiquement lorsqu’une équipe de développement commence à appliquer les différentes pratiques issues de méthodes agiles comme eXtreme Programming, la question des tests finit par venir. Lorsque l’équipe a compris la nécessité d’écrire des tests, elle risque de se heurter très rapidement à quelques obstacles. Un de ceux là concerne notamment les types de tests. C’est ainsi que l’on se retrouve généralement avec un jeu de tests JUnit qui vérifient par exemple les résultats des appels HTTP vers des Web Services REST déployés dans des…

Lire la suite
Méthode

Le ROI du TDD ?

Nous avons chez OCTO, des mailings très actives sur lesquelles les consultants posent des questions et débattent de sujets techniques, méthodologiques, fonctionnels,...

Je suis souvent soufflé par la qualité de ces débats.

Histoire de rendre un peu visible cet iceberg, j'ai prévu de prendre certains threads intéressants pour les restituer sur notre blog. Voici donc, pour démarrer, une version abrégée d'une discussion sur le ROI des approches de développement piloté par les tests. Merci à Misters F, C, G et S pour leurs contributions involontaires et tronquées...


Pour la Nième fois, un client me demande : "et le Test Driven Développement (TDD), ça va me coûter combien au final ?"

  • Il comprend les apports / la diminution des risques ....
  • Il comprend également que ça va lui coûter : il y a des développements, à créer, maintenir, refactorer.
  • Intuitivement, il a l'impression que ça colle : apports >> coût initial
  • Il voudrait des chiffres, des nombres, une formule magique, lui permettant de vendre cette démarche autour de lui

Est-ce qu'on a des éléments pour répondre précisément à cette question redondante ?

J'ai trouvé cette étude, couvrant les aspects ROI du TDD :

http://www.ipd.uka.de/~exp/xp/edser03.pdf

Vous en pensez quoi ?

Mister F

Lire la suite