Quelle est la différence entre les frameworks de test unitaire ScalaTest et Scala Specs?

Les deux sont des frameworks de tests unitaires compatibles BDD (Behavior Driven Development) pour Scala écrits en Scala. Et Specs est basé sur peut également impliquer le framework ScalaTest . Mais qu'est-ce que Specs n'offre pas ScalaTest? Quelles sont les différences?

Specs et ScalaTest sont tous deux de bons outils avec des utilisateurs satisfaits, mais ils diffèrent de plusieurs manières. Vous voudrez probablement en choisir un comme principal outil de test dans Scala, mais vous ne devez pas abandonner l'autre car vous pouvez utiliser des morceaux des deux. Si vous aimez la FeatureSpecsyntaxe de ScalaTest et la syntaxe Mockito de specs, par exemple, vous pouvez placer les deux fichiers jar dans votre chemin de classe et utiliser les deux en même temps. Ici, je vais essayer de capturer les principales différences de philosophie de conception que j'ai remarquées entre les spécifications et ScalaTest.

La principale différence philosophique entre les outils est probablement que les spécifications sont conçues pour le développement axé sur le comportement (BDD), tandis que ScalaTest est plus général. ScalaTest fournit des caractéristiques que vous pouvez mélanger pour obtenir le comportement que vous préférez dans vos classes de test, y compris BDD, et vous pouvez également définir facilement votre propre comportement si vous voulez quelque chose de différent.

ScalaTest supports BDD par son Spec, FeatureSpec, WordSpec, FlatSpecet GivenWhenThentraits, et a aussi des traits que vous pouvez mélanger pour obtenir une belle syntaxe matcher. Si vous aimez "devrait", vous mélangez dans ShouldMatchers. Si vous aimez "must", vous mélangez MustMatchers. Mais si vous aimez BDD mais que vous n'aimez pas la syntaxe matcher, vous pouvez simplement utiliser l'un des traits Spec de ScalaTest sans mélanger dans un trait matchers. Specs a une classe de spécification que vous étendez et vous devez utiliser le mot «must» dans vos expressions matcher. Une grande différence philosophique qui est évidente ici est que ScalaTest vous donne beaucoup plus de choix. Pour faciliter la navigation dans cet espace de choix, je propose ici un arbre de décision:

http://www.scalatest.org/quick_start

La syntaxe du matcher est également différente entre ScalaTest et specs. Dans ScalaTest, j'ai essayé de voir jusqu'où je pouvais aller avec la notation d'opérateur, et je me suis retrouvé avec des expressions de correspondance qui se lisent beaucoup comme des phrases anglaises, avec des espaces entre les mots. La syntaxe du matcher de spécifications exécute davantage les mots avec la casse camel.

Specs a plus de matchers que ScalaTest, et je pense que cela reflète une différence d'attitude de conception. En fait, j'ai coupé probablement 2/3 de la syntaxe du matcher que j'ai construite et envisagée pour la publication. J'ajouterai plus de matchers dans les prochaines versions, mais je voulais être sûr de savoir que les utilisateurs voulaient réellement quelque chose avant de l'ajouter. Cependant, les correspondants de ScalaTest incluent une syntaxe de correspondance de propriété dynamique qui prend une partie de cette marge. Par exemple, dans Specs, vous pouvez écrire sur un java.io.File:

file must beDirectory

Cela invoquera le isDirectoryet s'assurera qu'il est vrai. ScalaTest n'a pas de correspondance spéciale pour le moment java.io.Files, mais dans ScalaTest, vous pouvez simplement utiliser une vérification dynamique comme celle-ci:

file must be a ('directory)

Chaque fois que vous passez un symbole après be, il utilisera la réflexion pour rechercher (dans ce cas) une méthode ou un champ nommé directoryou une méthode nommée isDirectory. Il existe également un moyen de rendre cela statique, en définissant a BePropertyMatcher(qui ne nécessite généralement que 2 ou 3 lignes de code). Donc, fondamentalement, dans ScalaTest, j'essaie de fournir plus de fonctionnalités avec moins d'API.

Une autre différence d'attitude de conception générale entre les spécifications et ScalaTest implique des conversions implicites. Par défaut, vous n'obtenez qu'une seule conversion implicite lorsque vous utilisez ScalaTest, qui est celle qui place l' ===opérateur sur tout. (Si vous en avez besoin, vous pouvez "désactiver" cette conversion implicite avec une seule ligne de code. La seule raison pour laquelle vous auriez besoin de le faire est que vous essayiez de tester quelque chose qui a son propre ===opérateur et que vous obtenez un conflit. ) ScalaTest définit de nombreuses autres conversions implicites, mais pour les utiliser, vous devez les «inviter» explicitement dans votre code en les mélangeant dans un trait ou en faisant une importation. Lorsque vous prolongez la classeSpecificationdans les spécifications, je pense que vous obtenez à peu près des dizaines de conversions implicites par défaut. Je ne sais pas à quel point cela importera dans la pratique, mais je pense que les gens voudront tester du code qui utilise leurs propres implicits, et parfois il peut y avoir un conflit entre les implicits du framework de test et ceux du code de production. Lorsque cela se produit, je pense qu'il peut être plus facile de contourner le problème dans ScalaTest que les spécifications.

Une autre différence d'attitude de conception que j'ai remarquée est le confort avec les opérateurs. Un objectif que j'avais était que tout programmeur regardant le code de test de quelqu'un d'autre qui utilise ScalaTest soit capable de deviner quelle était la signification sans rien chercher dans la documentation de ScalaTest. Je voulais que le code client ScalaTest soit totalement évident. Une façon dont cet objectif s'est manifesté est que ScalaTest est très prudent sur les opérateurs. Je ne définis que cinq opérateurs dans ScalaTest:

• ===, ce qui signifie égal
• >, ce qui signifie supérieur à
• <, moins que
• >=, Meilleur que ou égal
• <=, inférieur ou égal.

C'est tout. Donc, ces choses ressemblent à peu près à ce que cela signifie. Si vous voyez dans le code de quelqu'un d'autre:

result should be <= 7

J'espère que vous n'aurez pas besoin de consulter la documentation de l'API pour deviner ce que cela <=signifie. En revanche, les spécifications sont beaucoup plus libres avec les opérateurs. Rien de mal à cela, mais c'est une différence. Les opérateurs peuvent rendre le code plus concis, mais le compromis est que vous pourriez avoir à courir à la documentation lorsque vous trouvez des choses comme ->-, >>, |, |>, !ou ^^^(qui ont tous une signification particulière dans les specs) dans le code de test de votre collègue.

Une autre différence philosophique est que j'essaie de rendre un peu plus facile dans ScalaTest d'utiliser un style fonctionnel lorsque vous devez partager un appareil, alors que Specs par défaut continue la tradition de l' approche setUpet tearDownpopularisée par JUnit, dans laquelle vous réaffectez les vars avant chaque test. Cependant, si vous voulez tester de cette façon, c'est aussi très facile dans ScalaTest. Vous avez juste besoin de mélanger le BeforeAndAftertrait.

Pour plus d'informations sur ScalaTest, vous pouvez regarder la présentation "Get Higher with ScalaTest" que j'ai donnée à la conférence Devoxx 2009 ici:

http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about

Les principales différences sont (principalement du point de vue des spécifications :-)):

• ScalaTest fournit plus de "styles de test" que de spécifications (vous pouvez visiter chaque puce sur la page de démarrage rapide pour obtenir une vue détaillée de chaque style)

• ScalaTest et les spécifications ont un ensemble différent de matchers. Vous pouvez les comparer ici pour ScalaTest et ici pour les spécifications. De ce côté-là, les spécifications ont beaucoup de petites fonctionnalités que vous aimerez peut-être lors de la rédaction de votre spécification: les matchers xml, la composition des matchers (un moyen facile de réutiliser les matchers en les transformant), des échecs précis, des différences détaillées pour les longues chaînes, .. .

• Mockito a reçu un bon support BDD dans les spécifications: Mockito

• specs a des DataTables qui permettent de regrouper beaucoup de petits exemples dans une sorte de tableau (si vous pouvez supporter les opérateurs utilisés comme délimiteurs de table)

• Dans les spécifications, vous pouvez définir des exemples imbriqués sous forme de libidum et automatiquement nettoyés à tous les niveaux

Il s'agit certainement d'une comparaison très partielle et biaisée et de nombreuses autres différences existent (et les bibliothèques évoluent encore, ...).

En fin de compte, je pense que cela dépend vraiment de votre style de test / spécification. Si c'est simple (structure de spécification simple, configurations, attentes, ...) alors les deux bibliothèques apparaîtront très similaires. Sinon, les deux ont leur avis sur la façon dont les choses devraient être faites. En guise de dernier exemple, vous pouvez jeter un œil au marquage: dans ScalaTest et dans les specs .

J'espère que ça aide.

Autant que je sache, à part quelques fonctionnalités hautement spécialisées, cela revient à une préférence personnelle en fonction du style.

Le support IDE peut être un autre point

J'ai essayé de faire fonctionner Specs avec Eclipse via JUnit, et j'ai trouvé que la solution officielle était un peu "hacky". Configuration des spécifications: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

L'intégration de ScalaTest (également via JUnit) avec semble un peu moins piratée. Pourtant, je n'ai aucun d'entre eux pour fonctionner aussi bien que JUnit et Java.

Configuration de ScalaTest: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

Si un facteur de décision est le temps de compilation, scalatest semble mieux fonctionner.

Nous utilisons actuellement specs2 dans notre projet, mais souffrons de temps de compilation lents dans les tests. Je viens de terminer un POC en passant au scalatest et j'ai vu les temps de compilation baisser d'un facteur d'environ 0,82 juste en changeant les 2 frameworks dans certaines de nos sources.