[Sondage] Quel framework de test préférez-vous ? (fr)

que viennent faire shoulda et cucumber dans la liste :D

Je préfère Riot, que je trouve concis et pas trop chargé en concept ou en usage de syntaxes inhabituelles. J’aime bien la façon dont le test est orienté en l’utilisant : on définit un contexte où un objet est créé ou légérement modifié, et puis on rajoute une série d’assertions simples qui ne modifient pas l’objet testé (du moins, c’est comme ça que je l’utilise).

test-unit et minitest/unit tendent à être assez verbeux (le fait d’avoir des ``def test_quelquechose`` en particulier me dérange). La syntaxe pas toujours intuitive assert_something(expected, actual) tend aussi à me déranger (je préfère quelque chose comme assert(expected).equals actual). Minitest tend quand même à être mieux, en proposant plus de méthodes pour faire des assertions courantes.

RSpec est sans doute celui que j’aime le moins. Tout ne reste pas toujours cohérent (comme should == obj mais should be_a(Thing), ou, comme autre cas particulier, expect { foo }.to.something), ce qui rend le tout plus difficile à retenir. En plus, il est souvent plus lent que les autres frameworks de tests de 1 ou 2 ordres de grandeurs.

Cucumber, je n’y vois même pas d’intérêt… (quant à Shoulda, je n’y ai jamais touché).

@Mon_Ouïe Je ne ne connais pas tous les frameworks cités mais j'ai pas mal utilisé Test-unit, Minitest Rspec et cucumber. et je trouve que ta critique de Rspec et Cucumber est franchement biaisée. La plupart du temps, les tests écrits avec foo.should se lisent très bien et c'est là leur plus grand avantage. Les tests sont IMHO une documentation vivante du code et c'est donc très important qu'ils soient facile à lire, même s'ils sont un peu plus difficiles à écrire. Les test écrits avec expect sont plus rares mais servent à nouveau quand l'intention du test est plus flagrante que si on avait utilisé should. Je trouve beaucoup plus clair expect{foo}.to raise_error que set_expected_error(true):foo.

Quant à Cucumber, sont intérêt est complémentaire à Un autre framework de test. C'est la documentation vivante des use cases de ton application et un outil de design extrêmement puissant. Plutot que d'essayer de maintenir une documentation avec des scnéarios d'utilisations qui deviennent obsolète au moindre refactoring, on en fait des tests d'intégration qui documente clairement les inputs valides et les outputs attendus. Les exemples cucumber (je n'ai pas les considérer comme des tests) sont en plus un outil très pratique lors des phases de refactoring pendant lesquelles on change le code et donc les tests unitaires mais que les features (et donc les exemples cucumber) doivent toujours fonctionner comme avant (sinon ce ne serait pas un refactoring)

sorry pour les typos, j'espérais qu'il y ait un bouton edit