Autrement dit, opposer le full stack à l'unitaire n'est pas vraiment une bonne idée

Une énorme liste de chaînes de caractères foireuse. Très pratique pour réaliser des tests

Super chouette idée !

Intéressant ...
Surtout parce qu'on fait du BDD sans interface web (genre pas comme fitnesse, quoi)

"The first step in becoming a better programmer is to let go of the conviction that we can code it once and get it right on the first write."

Je n'avais jamais pensé à créer des sous-classes anonymes dans mes tests pour en faire des quasi-mocks ... Et c'est vraiment une chouette idée ! Parce que je trouve toujours les syntaxes des mocks un peu ... curieuses

Effectivement : avoir sous la main un vrai testeur, c'est à la fois une bénédiction et une malédiction

Chouette article sur le devenir des tests

L'idée est très séduisante, mais je serais tenté de dire qu'il manque des morceaux dans l'API

Automate everything u can; that which u can't automate, make automatable

Chouette idée pour tester les modifications faites au système.

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.