Dans un précédent post, j’avais déjà évoqué l’insuffisance de l’indicateur « couverture de test » à lui seul pour garantir la détection de régressions. Pour résumer, un autre indicateur permettant de répondre aux questions « mes tests me protègent-ils contre d’éventuelles régressions? » ou formuler autrement « Quel est le niveau de confiance que j’ai dans mes tests? » doit être trouvé.

Deux idées existent. La méthode plus simple consiste à compter le nombre d’assertions réalisées: efficace et simple à mettre en oeuvre puisque cette solution repose sur un simple grep (comme si grep était simple…).
L’autre méthode repose sur le principe suivant:

Le code de test « valide » le code métier. le code métier peut valider le code de test…

Alors concrètement comment faire?! comment l’implémenter? Comme j’avais envie de coder, voilà « l’histoire » d’un POC visant à valider les principes précédemment énoncés.

(Lire la suite…)

Dans ce podcast, Olivier Hoareau répond à 3 questions de Pierre Pezziardi :

1. Comment monter en complexité / industrialiser une application PHP ?
2. L’approche TDD est-elle outillée en PHP ?
3. Comment faire des applications Ajax en PHP ?

Dans tout projet, les tests occupent une place très particulière. Leur vocation première est de s’assurer que le logiciel répond au besoin. Ils assurent ainsi le lien entre le monde des utilisateurs et le monde du développement. Les tests se retrouvent de manière très formelle – quasi juridique – dans le process de validation (le « PV de recette »). Ce rôle de point d’orgue du projet (sa conclusion) occulte très souvent la place réelle des tests, on oublie qu’ils ont participé très en amont à l’élaboration du livrable : derrière un PV de recette dûment signé, combien de bugs ont dû être préalablement corrigés, combien de chapitres a-t-il fallu revoir dans les spécifications ? Ces ajustements n’ont pas été produits ex nihilo, ils sont le résultat de la constatation d’une anomalie, d’un test en fait. S’ils ne sont pas formalisés, on les retrouve indirectement dans les écrits du projet : soit sous forme de complément de spécifications, soit aussi sous forme de correction de bug.

Lorsque le test n’est plus formalisé  » sous le manteau  » mais fait l’objet d’une démarche systématisée, on parle de démarche pilotée par les tests.

Trop souvent cette démarche est opposée à l’approche classique, et ce de façon manichéenne. Nous allons voir au contraire que les deux démarches sont complémentaires et que les outils correspondants peuvent être facilement intégrés.
(Lire la suite…)

Comme vous avez pu le voir, nous avons lancé une série de podcasts sur notre blog.

Vous pouvez écouter ces podcasts directement sur le blog ou vous abonner au fil RSS dédié pour les télécharger sur votre lecteur mp3 avec le lien suivant http://blog.octo.com/wp-content/uploads/images/feeds/podcast.php

Pour les utilisateurs de iTunes, il suffit de cliquer sur ce lien ou d’effectuer les opérations suivantes :

1. Copier le lien http://blog.octo.com/wp-content/uploads/images/feeds/podcast.php
2. Ouvrir iTunes
3. Aller dans le menu « Avancé | S’abonner au podcast… », coller le lien et cliquer sur OK

Bonne écoute !

Dans ce podcast, Olivier Hoareau répond à 1 question de Jean-François Hélie :

1. Comment faire de l’intégration continue en PHP ? des outils ?

(Lire la suite…)

L’annuaire pages blanches est une fonctionnalité que l’on retrouve très fréquemment dans le portail intranet d’une société. Cet annuaire est l’outil qui vous fournit les informations sur vos collègues préférés lorsque vous en avez besoin. Les données pages blanches contiennent les données de référence de la société pour un certain nombre d’informations liées aux collaborateurs. Ainsi d’autres applications du système d’information souhaitent elles aussi les utiliser.
Une des solutions pour mettre à disposition ces données à un ensemble d’applications est d’interposer un  » émissaire «  au dessus de l’annuaire afin de mutualiser l’exposition de ses services.

Cet article a pour objectif de montrer un exemple de réalisation d’un émissaire au dessus d’un annuaire LDAP en utilisant Grails et les web services REST.
(Lire la suite…)

Publiée dans le dernier 01 du 7 mars 2008 la chronique Pourquoi les méthodes agiles peinent à pénétrer l’entreprise a été unilatéralement retitrée en « L’échec des méthodes agiles », dur contresens.

Le texte évoquait la difficulté à intégrer le facteur qualité dans le processus de construction des applications … il subit, c’est de bonne guerre, les défauts du processus de publication du Groupe Tests. Un erratum sera publié au prochain numéro.

Dans ce podcast, Olivier Hoareau répond à 1 question de Jean-François Hélie :

1. Quels sont les ateliers de développements, IDE disponibles en PHP ?

(Lire la suite…)

Dans ce podcast, Olivier Hoareau répond à 5 questions de Thomas Vial sur PHP.

(Lire la suite…)

Lorsqu’une DSI souhaite mettre en oeuvre une Architecture Orientée Services (SOA), il lui est souvent conseillé de suivre une démarche en cascade qui part des processus métier de l’entreprise et qui visent à définir des services ré-utilisables. Même en supposant que ce long processus réussisse, la matérialisation informatique de ces services dans le SI passe généralement par de lourds projets de refonte de l’existant qui est généralement peu aligné sur ces visions théoriques. Qui peut alors réalistement défendre auprès de sa Direction Générale un projet de refonte même partiel de son SI aux seules fins de le rendre SOA ?
(Lire la suite…)