Les besoins en terme de qualité de code amènent de plus en plus de projets à s’intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits « de couverture de tests » sont utilisés en complément.
Loin de moi l’idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

• fournir une valeur quantitative représentant la part de logiciel testé
• fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J’y vois là le double avantage :

• de mieux maitriser le risque. Le code non testé est connu.
• de permettre d’améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu’un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D’aucuns diront que si on fait du TDD (« Test Driven Development »), le code non testé est inutile et n’aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd’hui…

Reste que cet indicateur de « couverture de test » se contente de « voir » le code exécuté. That’s all et ca n’est peut-être pas suffisant.
(Lire la suite…)

J’ai trouvé à plusieurs reprises lors d’audits d’optimisation de performances des soucis liés à une mauvaise utilisation d’hibernate, d’où le nom d’antipattern d’utilisation d’Hibernate.

Contexte

Utilisation d’Hibernate en Java (et .Net je suppose).
On cherche à accéder à un objet en Java via sa clé primaire. La requête est effectuée via une Query Hibernate.
Exemple de code:

1
2
3

Query tQuery =getSession().createQuery("from ParamCourtierPo where codeBanque=:codeBanque");
tQuery.setInteger("codeBanque", pParamCodeBanque);
ParamCourtierPo param = (ParamCourtierPo) tQuery.uniqueResult();

(Lire la suite…)

Comme beaucoup d’autres, j’ai commencé à faire du pair programming sans le savoir, en dehors même d’un cadre de méthodes agiles. J’intervenais sur un projet de développement de librairie de calculs de risque financier et le langage était le C++. J’avais la chance d’avoir avec moi une collègue à la fois compétente et sachant réellement travailler en équipe. Je me souviens que nous avons mené à plusieurs reprises des séances en binôme devant le même écran pour résoudre les problèmes les plus difficiles.
(Lire la suite…)

Dans nos missions chez nos clients, il nous arrive régulièrement d’utiliser des ESB (Enterprise Service Bus), pour créer une couche de médiation, gérer des flux, etc.
Mais parfois, on peut oublier ce qu’un tel acronyme de trois lettres signifie (TLA en anglais : Three Letter Acronym).
J’ai demandé à notre ami Google de me dire ce qu’il pensait de cet acronyme et de sa définition :

Google France me propose : Encéphalopathie Spongiforme Bovine
Et Google.com suggère : Empire Strikes Back

Alors, les ESB, est-ce une maladie mortelle ou bien une conspiration des éditeurs hégémoniques ?
Faut-il être un maître Jedi pour s’en sortir dans le monde cruel des ESB ?

Bienvenue sur le blog d’OCTO Technology, Cabinet d’architecture en Système d’Information.