Quelle est la différence entre ScalaTest et Scala Specs infrastructures de tests unitaires ?

Question

Les deux sont des infrastructures de test unité capable de BDD (Behavior Driven Development) pour Scala écrit en Scala. Et fiche <strike>repose sur</strike> peut également impliquer le cadre ScalaTest . Mais que fait la fiche ScalaTest n’est pas d’offrir ? Quelles sont les différences ?

Answer 1

Spécifications et ScalaTest sont tous deux de bons outils avec des utilisateurs satisfaits, mais ils diffèrent à plusieurs égards. Vous aurez probablement envie de choisir l'un comme votre principal outil de test en Scala, mais ne doivent pas abandonner les autres parce que vous pouvez utiliser des morceaux à la fois. Si vous aimez ScalaTest de l' FeatureSpec de la syntaxe et des specs' Mockito de la syntaxe, par exemple, vous pouvez mettre les deux fichiers jar dans le classpath et utiliser les deux en même temps. Ici, je vais essayer et de s'emparer de la principale philosophie de conception différences que j'ai remarqué entre les spécifications et ScalaTest.

Probablement la principale différence philosophique entre les outils est les specs, c'est conçu pour Behavior-Driven Development (BDD), alors que ScalaTest est plus général. ScalaTest fournit les traits que vous pouvez mélanger l'ensemble pour obtenir le comportement que vous préférez dans vos classes de test, y compris la BDD, et vous pouvez également définir votre propre comportement si vous voulez quelque chose de différent.

ScalaTest prend en charge BDD grâce à son Spec, FeatureSpec, WordSpec, FlatSpec, et GivenWhenThen traits, et a également des traits de caractère que vous pouvez mélanger pour obtenir une belle comparateur de syntaxe. Si vous aimez "devrait", vous mélangez dans ShouldMatchers. Si vous aimez le "doit", on mélange en MustMatchers. Mais si vous aimez la BDD, mais n'aime pas la correspondance de la syntaxe, vous pouvez simplement utiliser l'une des ScalaTest de Spec traits sans les mélanger dans un rapprochement trait. Spécifications a une Spécification de la classe que vous étendez, et vous devez utiliser le mot "doit" dans votre correspondance des expressions. Une grande différence philosophique qui est ici évidente est que ScalaTest vous donne beaucoup plus de choix. Pour faire de cet espace de choix, plus facile à naviguer, je fournir un arbre de décision ici:

http://www.scalatest.org/quick_start

Le comparateur de syntaxe est également différente entre les ScalaTest et les spécifications. Dans ScalaTest j'ai essayé de voir jusqu'où je pouvais aller avec l'opérateur de notation, et a terminé avec la correspondance des expressions qui se présentent à peu près comme l'anglais des phrases, avec des espaces entre les mots. Spécifications comparateur de syntaxe exécute les mots de plus de chameau cas.

Spécifications a plus de rapprochement que ScalaTest, et qui, je pense, reflète une différence dans l'attitude de conception. J'ai fait couper probablement 2/3 de la correspondance de la syntaxe que j'ai construit et admissible à la libération. Je vais ajouter plus de rapprochement dans les futures versions, mais je voulais être sûr que je savais que les utilisateurs voulaient réellement quelque chose avant que je l'ai ajouté. Cependant ScalaTest du rapprochement inclut une propriété dynamique comparateur de syntaxe du que mou. Par exemple dans les Specs, vous pouvez écrire sur un java.io.File:

file must beDirectory

Cela invoquer l' isDirectory et assurez-vous qu'il est vrai. ScalaTest ne pas avoir de rapprochement pour java.io.Files actuellement, mais dans ScalaTest, vous pouvez simplement utiliser un contrôle dynamique comme ceci:

file must be a ('directory)

Quand vous passez un symbole dans l'après be, il va utiliser la réflexion pour rechercher (dans ce cas) d'une méthode ou un champ nommé directory ou une méthode nommée isDirectory. Il y a aussi une façon de faire cela statique, par la définition d'un BePropertyMatcher (qui ne nécessite 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 conception générale de l'attitude de la différence entre les spécifications et ScalaTest implique des conversions implicites. Par défaut, vous n'obtenez qu'une conversion implicite lorsque vous utilisez ScalaTest, qui est celui qui met l' === opérateur sur tout. (Si vous en avez besoin, vous pouvez "désactiver" ce conversion implicite avec une seule ligne de code. La seule raison pour laquelle vous avez besoin de le faire est si vous étiez en train de tester quelque chose qui a sa propre === de l'opérateur, et vous obtenez un conflit.) ScalaTest définit bien d'autres conversions implicites, mais pour les utiliser, vous devez explicitement "inviter" dans votre code en mélangeant, dans un trait de caractère ou d'effectuer une importation. Lorsque vous étendez la classe Specification dans les specs, je pense que vous avez assez bien obtenir des dizaines de conversions implicites par défaut. Je ne suis pas sûr de savoir comment beaucoup de qui importe dans la pratique, mais je suppose que les gens vont vouloir tester du code qui utilise leur propre implicites, et parfois il peut y avoir un conflit entre le framework de test du implicites et ceux de la production de code. Quand cela arrive, je pense qu'il peut être plus facile de contourner le problème en ScalaTest que les specs.

Une autre différence dans la conception de l'attitude que j'ai remarqué, c'est le confort avec les opérateurs. Un objectif que j'avais était que n'importe quel programmeur de regarder quelqu'un d'autre le code de test qui utilise ScalaTest serait capable de deviner ce que le sens était sans regarder quoi que ce soit dans le ScalaTest de la documentation. Je voulais ScalaTest code client drop dead évident. Une manière de but manifeste est que ScalaTest est très conservateur sur les opérateurs. Je ne définissent cinq opérateurs ScalaTest:

• ===, ce qui signifie égal
• >, ce qui signifie plus de
• <, moins de
• >=, supérieure ou égale
• <=, inférieur ou égal.

C'est tout. De sorte que ces choses assez bien ressembler à ce que veux dire. Si vous voyez quelqu'un d'autre code:

result should be <= 7

Mon espoir est que vous n'aurez pas besoin de courir à la documentation de l'API de deviner ce qu' <= moyens. En revanche, les specs, c'est beaucoup plus libre avec les opérateurs. Rien de mal à cela, mais il ya une différence. Les opérateurs peuvent rendre le code plus concis, mais le compromis est que vous pouvez exécuter à la documentation lorsque vous trouver des choses comme ->-, >>, |, |>, !ou ^^^ (qui ont tous une signification particulière dans les Specs) dans votre collègue du code de test.

Une autre différence philosophique, c'est que je ne l'essayer et de le rendre juste un peu plus facile dans ScalaTest d'utiliser un style fonctionnel lorsque vous avez besoin de partager un luminaire, alors que les Spécifications par défaut se poursuit la tradition de l' setUp et tearDown approche popularisée par JUnit, dans lequel vous réaffectez vars avant chaque test. Toutefois, si vous souhaitez tester de cette façon, il est également très facile à ScalaTest. Vous avez juste besoin de mélanger dans l' BeforeAndAfter trait.

Pour plus de perspicacité dans ScalaTest, vous pouvez regarder le "monter de plus en Plus avec ScalaTest" présentation que j'ai donné en 2009 à la conférence Devoxx ici:

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

Answer 2

Les principales différences sont la plupart du temps à partir d'un specs point de vue :-) ):

• ScalaTest fournit plus de "tests de styles" que les spécifications (vous pouvez visiter chaque point sur le démarrage rapide de la page pour obtenir une vue détaillée de chaque modèle)

• ScalaTest et les spécifications ont un ensemble différent de rapprochement. Vous pouvez comparer ici pour ScalaTest et ici pour les specs. Sur cet aspect des choses, les spécifications a beaucoup de petites fonctionnalités que vous pouvez, comme lors de la rédaction de votre cahier des charges: xml de rapprochement, rapprochement composition (un moyen facile de réutiliser les allumettes en les transformant), précise les échecs, les différences en détail pendant de longues chaînes de caractères, ...

• Mockito a été donné une belle BDD de soutien dans les specs: Mockito

• spécifications a les tables de données qui permettent de regrouper une multitude de petits exemple dans une sorte de table (si vous ne pouvez supporter les opérateurs d'être utilisé comme table de délimiteurs)

• Dans les specs, vous pouvez définir des exemples qui sont imbriquées comme libitum et automatiquement nettoyé à chaque niveau

C'est certainement un très partielle et partiale de la comparaison et de nombreuses autres différences existent (et les bibliothèques sont encore en évolution, ...).

À la fin de la journée, je pense que cela dépend vraiment de vos tests/spécification de style. Si c'est simple (simple spécification de la structure, des installations, des attentes, ...) puis les deux bibliothèques apparaissent très semblables. Sinon, les deux ont leur point de vue sur la façon dont les choses devraient être faites. Comme un dernier exemple de cela, vous pouvez avoir un coup d'oeil à de marquage: dans ScalaTest et dans les spécifications.

J'espère que cette aide.

Answer 3

Autant que je sache, sauf quelques fonctionnalités hautement spécialisées, il descend à vos préférences personnelles selon le style.

Answer 4

IDE de soutien peut être un autre point de

J'ai essayé d'obtenir des Spécifications à travailler avec Eclipse via JUnit, et j'ai trouvé la solution officielle pour être un peu "hacky". Spécifications de l'installation: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

ScalaTest de l'intégration (également via JUnit) avec semble un peu moins hacky. Pourtant, je n'ai pas de travailler ainsi que JUnit et Java.

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