Java c'est génial, et il y a plein d'outils de tests. Mais la liste n'est pas complète (par exemple il manque Contiperf)

C'est pour ça que je suis passé il y a quelques temps aux visiteurs, et autres patterns un peu intelligents. En fait, utiliser l'introspection, c'est un anti-pattern.

Le piratage de systèmes d'information en version facile (et en java)

Un outil qui n'exécute que les tests impactés par les modifications du dernier commit. Ca me paraît assez chouette comme idée (et ça pourrait avantageusement remplacer infinitest)

Et pour la blague, comment arrêter une appli java dans un conteneur quand le conteneur s'arrête, c'est croquignolet ...

Une intéressante collection d'outils de validation statique

Mon client vient de me faire découvrir cette histoire de zero copy. Java NIO, c'est quand même génial !

Un jour, je comprendrai pourquoi Oracle a racheté Sun ...

Valider l'organisation du code dans des tests unitaires est une sacrément bonne idée. Et le DSL est semble-t-il assez bien fichu.

Très chouette. J'aime beaucoup le fait que DSpot ne génère pas une tonne de tests supplémentaires.

Bonne idée ! Dommage qu'il faille en passer par un agent d'instrumentation

Intéressant ... pour peu qu'on puisse "contrôler" le hasard, c'est-à-dire garantir que la liste de valeurs est raisonnablement la même à chaque test. Parce que sinon, les tests peuvent perdre en répétabilité.

Alors ça, c'est dingue. Je croyais que la JVM était rapide, mais ce code compilé en natif est encore plus rapide. Clairement, ça cible tous ces langages modernes qui n'existent que par leur disponibilité sous forme de binaires uniques

Pas mal du tout

Pas mal, c'est la première fois que je vois un argument contre var qui ait du sens.

Alors ça, je ne connaissais pas. Ca ne sert à mon avis plus à grand chose avec les types génériques ... Mais c'est quand même sacrément cool.

Je ne sais pas si c'est un si bon article (parce que je connais nettement mieux Maven que Gradle). Ce que j'en comprend en revanche colle à peu près avec ma vision du truc.

La variété, c'est effectivement bien. Mais Kotlin me fait toujours l'effet d'un certain opportunisme ...

Les checked exceptions sont-elles une erreur de conception du Java ? Peut-être bien ...

C'est un problème assez spécifique, mais très intéressant ...