Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Prochaines sessions inter-entreprises : 28-31 mars 2017 / 13-16 juin 2017
Sessions intra-entreprises sur demande.
Inscrivez-vous vite !

Résultats du sondage sur l'utilisation des assertions

Cela fait un moment que le sondage est disponible, il est donc temps de dépouiller les urnes.

Les résultats sont très partagés :

  • D'un côté, presque 40% d'entre vous n'utilisent pas les assertions, ou à reculons.
  • De l'autre côté, environ 30% les apprécient et les utilisent régulièrement.
  • Entre les deux, quelque 20% les utilisent lorsqu'ils y pensent et ont du temps à y consacrer, comme un bonus en quelque sorte.
  • Enfin, plus de 8% ne connaissent pas ce mécanisme.

Un joli diagramme en 3D et en couleurs (merci Google Charts) vaut mieux qu'un tableau plein de chiffres :



Je suis plutôt étonné du nombre de personnes utilisant les assertions : ce mécanisme est généralement assez méconnu.
De plus, il souffre à mon sens d'un gros défaut : il est désactivé par défaut à la compilation et à l'exécution. Cela entraîne deux conséquences :

  • tout d'abord, il est impossible et même dangereux de compter sur la présence (ou non) des assertions pour déterminer le comportement de l'application.
  • d'une part, le développeur souhaitant les utiliser doit ajouter manuellement une option (-ea) dans son IDE et au lancement de ses applications, ce que l'équipe d'exploitation peut refuser.

Certains estiment que les tests unitaires, plus pratiques et mieux intégrés aux chaînes de développement, rendent les mécanisme des assertions caduque. Pourtant, celles-ci possèdent un avantage unique : elles font partie du code même ! Il est donc impossible de les oublier ou de les perdre. De plus, bien utilisées, elles participent également à la documentation (technique) du code - une sorte de programmation par contrat à seule destination des développeurs qui reprendront le code.
Au final, je pense que les assertions complètent bien les tests unitaires, surtout dans les couches purement techniques comme les frameworks.

Mais il faut garder en mémoire les best practices :

The assert statement is appropriate for nonpublic precondition, postcondition and class invariant checking. Public precondition checking should still be performed by checks inside methods that result in particular, documented exceptions, such as IllegalArgumentException and IllegalStateException.


Commentaires

1. Le mardi 24 février 2009, 11:14 par HollyDays

Je relie cette méconnaissance et/ou cette méfiance ("le moins possible"/"jamais"/"ne connait pas" représentent 50% des réponses) au fait que de nombreux architectes logiciels se méfient toujours des assertions, ce qui rejaillit inévitablement sur les développeurs avec lesquels ils travaillent. Ces architectes ont appris les assertions avec le C/C++. Or dans ce langage, les assertions sont incompatibles avec une application vraiment robuste (on ne peut pas, de manière portable, récupérer d'une assertion : le programme s'arrête brutalement). Dans la tête de nombre d'entre eux, les assertions restent encore associées à cela (du debug), et ils ne voient donc pas vraiment la plus-value par rapport aux exceptions Java et à la richesse d'expression qu'elles offrent.

Bref, la programmation par contrats de Bertrand Meyer, pourtant si utile, a encore du chemin à faire avant d'être vraiment populaire. Et Sun a sans doute une part de responsabilité en ayant refusé de formaliser de véritables mécanismes pour définir des postconditions et des invariants de classes de manière déclarative (il faut passer par des outils spécialisés du type JContract ou via les aspects).

2. Le vendredi 27 février 2009, 16:03 par HollyDays

J'ai trouvé un petit plugin pour JAVAC qui force le test des assertions même si les assertions sont désactivées à l'exécution.

http://smallwiki.unibe.ch/adriankuh...

A tester...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.