Très bonne règle de nommage des tests, ça donne du sens
J'ai toujours pensé que ce genre d'outils de test était un complément indispensable à JUnit, même si parfois difficile à faire entrer dans le build.
Je tourne depuis uns acré moment autour de ces histoires de BDD. Et je pense que le moment est venu de se pencher un peu plus sur ces outils "de haut niveau".
Chouette outil d'expressions régulières en Javascript.
Oulalalala Ca m'a l'air d'être une fabuleusement bonne idée, ces assertions générées à partir du code métier de l'application
J'avais déja entendu parler de ce concept complètement dingue, mais j'avais oublié le nom du (ou des) frameworks qui peuvent permettre la mise en application du concept. Là, avec l'intégation maven/ant, c'est très chouette.
Sacrément intéressant. je me demande ce que ça donnera avec les method references de Java 8 ...
Bon, par contre, je suis peu satisafait par le "AT ENTRY" en chaîne de caractère pour spécifier le moment où renvoyer l'exception. Les enums sont faits pour ça, nom d'un chien !
Très bon article (normal chez Palantir) expliquant comment faire un test unitaire vérifiant qu'un memory leak n'existe plus. Ca ne marche toutefois aps dans mon cas, hélas.
Tiens c'est pas con comme idée de découpage des tests : appeler la classe dans laquelle on place les paquets de tests OnTestedTests, et mettre dans cette classe des classes internes When*, qui contiennent à leur tour les différentes méthodes de test. Faudrait que j'essaye, ça me paraît malin.
Il est bien cet article sur les tests unitaires. On croirait que c'est Eric Lefebvre qui l'a écrit.
Il se trouve que c'est ce que je fais de plus en plus : des tests linéaires, dont les méthodes portent des noms expliquant le comportement testé. Et surtout, SURTOUT, des tests réalisés avec hamcrest ou FEST-assert pour avoir le fameux assertThat(bidule, is(machin));
Tiens c'est marrant,c 'est ce que je fais de plus en plus. C'est spécialement pratique pour les tests utuilisant Weld : je démarre Weld dans mon test, et je lui demande de me charger une instance de ma classe de test, et ça roule
via http://java.dzone.com/
Marrant comme test. Cela dit, le fait que j'utilise ma souris de la main gauche alors que je suis droitier ne m'a pas aidé. Et certains questions m'ont plongé dans des abîmes de perplexité :
- croisez vos jambes, laquelle est au-dessus ?
- regardez un objet et fermez un oeil, lequel reste ouvert ? (j'ai dû le refaire 3-4 fois parce que je ne fermais pas un oeil SANS REFLECHIR)
Chouette article expliquant comment remplacer le pénible (mais standard @RunWith(Parameterized.class) par quelque chose de plus souple et donnant des résultats plus lisibles.
Chouette façon de tester un client HTTP tiens
Maïa Mazaurette a des problèmes de jouissance, il semble. MAIS d'une part ce ne sont pas les problèmes de tout le monde, et d'autre part elle écrit suffisament bien pour que même ça soit drôle plutôt que pathétique.
Une chouette petite lib pour faciliter l'écriture de code moyennement asynchrone.
Peut-être une solution de TDD moins coûteuse que Infinitest ...
Des tests jUnit qui envoient des notifications Nagios ... très pratique quand on n'est pas sûr de la fiabilité de certains composants.
easyb a quand même l'air vachement simple. Peut-être même simpliste. Mais en tout cas, il rend la tâche de spécification très agréable.
Je sais pas si ça peut sauver un développement mal engagé, mais en tout cas ça a l'air de permettre facilement d'écrire du code qui corresponde aux besoins exprimés.