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.