Qual é a diferença entre estruturas de teste de unidade ScalaTest e Scala especificações?

Question

Ambos são BDD (Behavior Driven Development) estruturas de teste de unidade capaz para Scala escrito em Scala. E Specs é construído em cima pode também envolver o ScalaTest quadro . Mas o que faz Specs oferta ScalaTest não? Quais são as diferenças?

Answer 1

Specs e ScalaTest são boas ferramentas com usuários felizes, mas diferem em vários aspectos. Você provavelmente vai querer escolher um como ferramenta de teste principal em Scala, mas não precisa desistir da outra, porque você pode usar pedaços de ambos. Se você gosta de sintaxe FeatureSpec de ScalaTest e sintaxe Mockito especificações, por exemplo, você pode colocar ambos os arquivos jar no classpath e usar os dois ao mesmo tempo. Aqui eu vou tentar capturar as principais diferenças filosofia de design que eu observei entre especificações e ScalaTest.

Provavelmente, a principal diferença filosófica entre as ferramentas é que specs é projetado para Behavior Driven Development (BDD), enquanto ScalaTest é mais geral. ScalaTest fornece características que você pode misturar em conjunto para obter o comportamento que você prefere em suas classes de teste, incluindo BDD, e você também pode definir facilmente o seu próprio comportamento, se você quiser algo diferente.

suportes ScalaTest BDD através de seus traços Spec, FeatureSpec, WordSpec, FlatSpec e GivenWhenThen, e também tem características que você pode misturar para obter uma sintaxe agradável correspondência. Se você gosta de "deveria", você misturar em ShouldMatchers. Se você gosta de "must", você misturar em MustMatchers. Mas se você gosta de BDD, mas não gosto de sintaxe de correspondência, você pode apenas usar um dos traços Spec do ScalaTest sem misturar em um matchers característica. Specs tem uma classe Especificação que você estender, e você deve usar a palavra "must" em suas expressões matcher. A diferença filosófica grande que é evidente aqui é que ScalaTest lhe dá muito mais opções. Para tornar este espaço de escolha mais fácil de navegar, eu forneço uma árvore de decisão aqui:

http://www.scalatest.org/quick_start

A sintaxe de correspondência também é diferente entre ScalaTest e especificações. Em ScalaTest Tentei ver quão longe eu poderia ir com notação operador, e acabou com expressões matcher que lêem muito parecido com frases em inglês, com espaços entre as palavras. Specs sintaxe de correspondência corre palavras juntas mais com caso camelo.

Specs tem mais matchers que ScalaTest, e que eu acho que reflete uma diferença de atitude design. Eu realmente cortar provavelmente 2/3 da sintaxe de correspondência que eu construí e considerada para a liberação. Vou acrescentar mais matchers em versões futuras, mas queria ter certeza de que eu sabia usuários realmente queria algo antes que eu acrescentou ele. No entanto matchers de ScalaTest inclui uma sintaxe da propriedade correspondência dinâmica leva um pouco do que folga. Por exemplo, em Specs você pode escrever em um java.io.File:

file must beDirectory

Isso irá chamar a isDirectory e verifique se ele é verdadeiro. não ScalaTest não tem nenhum matchers especiais para java.io.Files atualmente, mas em ScalaTest, você pode simplesmente usar um cheque dinâmica como esta:

file must be a ('directory)

Sempre que você passar um símbolo depois be, ele irá usar a reflexão para procurar (neste caso) um método ou campo chamado directory ou um método chamado isDirectory. Há também uma maneira de fazer este estático, definindo um BePropertyMatcher (que requer apenas 2 ou 3 linhas de código geralmente). Então, basicamente em ScalaTest I tentar dar mais funcionalidade com menos API.

Outra diferença atitude concepção geral entre especificações e ScalaTest envolve conversões implícitas. Por padrão, você tem apenas uma conversão implícita quando você usa ScalaTest, que é o que coloca o operador === em tudo. (Se você precisar, você pode "desligar" esta conversão implícita com uma linha de código. A única razão que você precisa para fazer isso é se você estivesse tentando algo teste que tem seu próprio operador ===, e você terá um conflito .) ScalaTest define muitas outras conversões implícitas, mas usá-los você precisa explicitamente "convidar"-los em seu código através da mistura de um traço ou fazer uma importação. Quando você estender a classe Specification em especificações que eu acho que você praticamente receber dezenas de conversões implícitas por padrão. Eu não tenho certeza quanto que importa na prática, mas eu acho que as pessoas vão querer código de teste que usa seus próprios implícitos, e às vezes pode haver um conflito entre implícitos do framework de teste e os do código de produção. Quando isso acontece, eu acho que pode ser mais fácil de contornar o problema em ScalaTest de especificações.

Outra diferença na atitude de design que eu tenho notado é conforto com operadores. Um objetivo que eu tinha era que qualquer programador olhando para código de teste de outra pessoa que usa ScalaTest seria capaz de adivinhar o que o significado era sem olhar qualquer coisa na documentação ScalaTest. Eu queria ScalaTest código de cliente para ser cair morto óbvio. Uma maneira que objetivo manifestou-se é que ScalaTest é muito conservador sobre operadores. Eu só definir cinco operadores em ScalaTest:

• ===, o que significa que é igual a
• >, o que significa maior do que
• <, menos de
• >=, maior ou igual
• <=, menor ou igual.

É isso. Então, essas coisas muito bem parecido com o que quer dizer. Se você vê no código de outra pessoa:

result should be <= 7

A minha esperança é que você não precisará executar a documentação da API para adivinhar o que isso significa <=. Por outro lado, especificações é muito mais livre com operadores. errado nada com isso, mas é uma diferença. Os operadores podem tornar o código mais conciso, mas a desvantagem é que você pode ter que executar a documentação quando você encontra coisas como ->-, >>, |, |>, !, ou ^^^ (que todos têm significados especiais em Specs) em código de teste do seu colega .

Uma outra diferença filosófica é que eu tentar fazê-lo apenas um pouco mais fácil em ScalaTest usar um estilo funcional quando você precisa compartilhar um dispositivo elétrico, enquanto Specs por padrão continua a tradição da abordagem setUp e tearDown popularizado por JUnit, no qual volta a atribuir vars antes de cada teste. No entanto, se você quiser testar dessa forma, também é muito fácil em ScalaTest. Você só precisa misturar na BeforeAndAfter característica.

Para mais detalhes sobre ScalaTest, você pode assistir a apresentação "Get Superior com ScalaTest" Eu dei na conferência de 2009 Devoxx aqui:

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

Answer 2

As principais diferenças são (principalmente a partir de um ponto de vista características :-)):

• ScalaTest fornece mais "testando estilos" de specs (você pode visitar cada ponto de bala na início rápido página para obter uma visão detalhada de cada estilo)

• ScalaTest e especificações têm um conjunto diferente de matchers. Você pode compará-los aqui para ScalaTest e < a href = "http://code.google.com/p/specs/wiki/MatchersGuide" rel = "noreferrer"> aqui para especificações. Por esse lado das coisas, especificações tem um monte de pequenos recursos que você pode gosto ao escrever sua especificação: matchers xml, composição matchers (uma maneira fácil de reutilizar matchers, transformando-os), falhas precisos, as diferenças detalhadas para longas seqüências, .. .

• Mockito foi dado um bom suporte BDD nas especificações: Mockito

• especificações tem DataTables que permitem agrupar um monte de pequeno exemplo em uma espécie de mesa (se você pode estar operadores sendo utilizados como delimitadores de mesa)

• Em especificações, você pode definir exemplos que estão aninhados como libidum e limpa-up automaticamente em todos os níveis

Esta é certamente uma comparação muito parcial e tendenciosa e existem muitas outras diferenças (e as bibliotecas ainda estão evoluindo, ...).

No final do dia, eu acho que ele realmente depende de seu teste / style especificar. Se é (estrutura especificação simples, configurações, expectativas, ...) simples, então ambas as bibliotecas irá aparecer muito semelhante. Caso contrário, ambos têm a sua opinião sobre como as coisas devem ser feitas. Como último exemplo disso você pode ter um olhar para a marcação: em ScalaTest e em especificações .

Espero que isso ajude.

Answer 3

Tanto quanto eu sei, salvo algumas características altamente especializados, que se resume a preferência pessoal de acordo com o estilo.

Answer 4

suporte IDE pode ser outro ponto

Eu tenho tentado obter Especificações para trabalhar com Eclipse através JUnit, e eu encontrei a solução oficial para ser um pouco "hacky". configuração Especificações: http://code.google.com/p/specs/wiki / RunningSpecs # Run_your_specification_with_JUnit4_in_Eclipse

A integração do ScalaTest (também através JUnit) com parece um pouco menos hacky. Ainda assim, eu não tenho qualquer um deles para o trabalho, bem como JUnit e Java.

Configuração ScalaTest: http: // grupos. google.com/group/scalatest-users/web/running-scalatest-from-eclipse

Answer 5

Se um fator de decisão é o tempo de compilação, ScalaTest parece ter um melhor desempenho.

No momento, estamos usando specs2 em nosso projeto, mas sofrem de tempos de compilação lento nos testes. Acabei de terminar um POC em se mudar para vezes ScalaTest e viu compilação cair por um fator de cerca de 0,82 apenas alternando as 2 estruturas em algumas das nossas fontes.