¿Cuál es la diferencia entre los marcos de prueba de unidades ScalaTest y Scala Specs?

Question

Ambos son marcos de prueba de unidad capaces de BDD (Desarrollo Dirigido por Comportamiento) para Scala escritos en Scala. Y Specs se basa en también puede implicar el marco ScalaTest. Pero, ¿qué ofrece Specs ScalaTest no? ¿Cuáles son las diferencias?

Answer 1

Las especificaciones y ScalaTest son buenas herramientas para usuarios satisfechos, pero difieren en varios aspectos. Es probable que desee elegir uno como su herramienta de prueba principal en Scala, pero no necesita renunciar a la otra porque puede usar piezas de ambos. Si le gusta la sintaxis y la sintaxis de Mockito de ScalaTest FeatureSpec, por ejemplo, puede poner ambos archivos jar en su classpath y usar ambos al mismo tiempo. Aquí intentaré capturar las principales diferencias de filosofía de diseño que he notado entre las especificaciones y ScalaTest.

Probablemente, la principal diferencia filosófica entre las herramientas es que las especificaciones están diseñadas para el desarrollo impulsado por el comportamiento (BDD), mientras que ScalaTest es más general. ScalaTest proporciona características que puede combinar para obtener el comportamiento que prefiera en sus clases de prueba, incluido BDD, y también puede definir fácilmente su propio comportamiento si desea algo diferente.

ScalaTest apoya BDD a través de sus Spec, FeatureSpec, WordSpec, FlatSpec y GivenWhenThen rasgos, y también tiene rasgos que se pueden mezclar para obtener una sintaxis matcher agradable. Si le gusta "debería", mezcle ShouldMatchers. Si le gusta "debe", mezcle en MustMatchers. Pero si le gusta BDD pero no le gusta la sintaxis de matcher, puede usar uno de los rasgos de Spec de ScalaTest sin mezclar en un rasgo de matcher. Specs tiene una clase de especificación que extiendes, y debes usar la palabra "must" en tus expresiones de matcher. Una gran diferencia filosófica que es evidente aquí es que ScalaTest te brinda muchas más opciones. Para hacer este espacio de elección más fácil de navegar, proporciono un árbol de decisión aquí:

http://www.scalatest.org/quick_start

sintaxis El matcher también es diferente entre ScalaTest y especificaciones. En ScalaTest traté de ver hasta dónde podía llegar con la notación del operador, y terminé con expresiones de matcher que se parecen mucho a las oraciones en inglés, con espacios entre las palabras. La sintaxis del mezclador de Specs ejecuta palabras juntas más con camel case.

Specs tiene más equivalentes que ScalaTest, y eso creo que refleja una diferencia en la actitud de diseño. En realidad, corté probablemente 2/3 de la sintaxis del emparejador que construí y consideré para su lanzamiento. Agregaré más marcadores en versiones futuras, pero quería asegurarme de que sabía que los usuarios realmente querían algo antes de que lo agregara. Sin embargo, los adaptadores de ScalaTest incluyen una sintaxis de emparejador de propiedad dinámica que absorbe parte de esa holgura. Por ejemplo, en Espec se puede escribir en un java.io.File:

file must beDirectory 

Esto invocará el isDirectory y asegurarse de que es cierto. ScalaTest no tiene ningún comparadores especiales para java.io.Files actualmente, pero en ScalaTest, es posible que utilices una comprobación dinámica de la siguiente manera:

file must be a ('directory) 

Cada vez que pasa un símbolo después de be, utilizará la reflexión a buscar (en este caso) un método o campo llamado directory o un método llamado isDirectory. También hay una forma de hacer esto estático, definiendo un BePropertyMatcher (que requiere solo 2 o 3 líneas de código generalmente). Básicamente, en ScalaTest intento proporcionar más funcionalidades con menos API.

Otra diferencia de actitud de diseño general entre las especificaciones y ScalaTest implica conversiones implícitas. Por defecto, solo obtiene una conversión implícita cuando usa ScalaTest, que es el que pone el operador === en todo. (Si es necesario, puede "desactivar" esta conversión implícita con una línea de código. La única razón por la que tendría que hacer eso es si estaba intentando probar algo que tiene su propio operador ===, y obtiene un conflicto .) ScalaTest define muchas otras conversiones implícitas, pero para usarlas necesita explícitamente "invitarlas" a su código mezclando un rasgo o haciendo una importación. Cuando extiendes la clase Specification en las especificaciones, creo que obtienes docenas de conversiones implícitas por defecto. No estoy seguro de cuánto importará en la práctica, pero creo que las personas querrán probar el código que usa sus propias implicaciones, y en ocasiones puede haber un conflicto entre las implicaciones del marco de prueba y las del código de producción. Cuando eso sucede, creo que puede ser más fácil solucionar el problema en ScalaTest que las especificaciones.

Otra diferencia en la actitud de diseño que he notado es la comodidad con los operadores. Uno de mis objetivos era que cualquier programador que examinara el código de prueba de otra persona que utilizara ScalaTest pudiera adivinar su significado sin buscar nada en la documentación de ScalaTest. Quería que el código del cliente de ScalaTest fuera obvio.Una forma en que esa meta se manifestó es que ScalaTest es muy conservador con respecto a los operadores. I sólo definen cinco operadores en ScalaTest:

• ===, lo que significa es igual a
• >, lo que significa mayor que
• <, a menos de
• >=, mayor que o igual
• <=, menos que o igual.

Eso es todo. Así que estas cosas se parecen mucho a lo que significa. Si ve en el código de otra persona:

result should be <= 7 

Mi esperanza es que usted no tendrá que correr a la documentación de la API de adivinar lo que los medios <=. Por el contrario, las especificaciones son mucho más libres con los operadores. No hay nada de malo en eso, pero es una diferencia. Los operadores pueden hacer que el código más conciso, pero la desventaja es que usted puede tener que ejecutar la documentación cuando encuentre cosas como ->-, >>, |, |>, !, o ^^^ (que todas tienen un significado especial en Especificaciones) en el código de prueba de su colega .

Otra diferencia filosófica es que yo trato de hacer es sólo un poco más fácil en ScalaTest de usar un estilo funcional cuando se necesita para compartir un accesorio, mientras Especificaciones por defecto continúa la tradición del enfoque setUp y tearDown popularizado por JUnit , en el que reasignas vars antes de cada prueba. Sin embargo, si quiere hacer la prueba de esa manera, también es muy fácil en ScalaTest. Solo necesita mezclar el rasgo BeforeAndAfter.

Para una visión más clara ScalaTest, se puede ver el "Obtener Superior con ScalaTest" presentación que hice en la conferencia de 2009 Devoxx aquí:

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

Answer 2

Hasta donde yo sé, salvo algunas características altamente especializadas, todo se reduce a las preferencias personales según el estilo.

Answer 3

Las principales diferencias son (sobre todo desde un punto de vista :-) especificaciones):

• ScalaTest proporciona más pruebas de "estilos" de las especificaciones (se puede visitar cada una viñeta en la página quick start para obtener una vista detallada de cada estilo)

• ScalaTest y especificaciones tienen un conjunto diferente de matchers. Puede compararlos here para ScalaTest y here para las especificaciones. Por el lado de las cosas, las especificaciones tienen muchas características pequeñas que te pueden gustar al escribir tu especificación: xml matchers, composición de matchers (una manera fácil de reutilizar los matchers transformándolos), fallas precisas, diferencias detalladas para cadenas largas, ... .

• Mockito se le ha dado un buen apoyo BDD en especificaciones: Mockito

• especificaciones ha DataTables que permiten agrupar una gran cantidad de pequeño ejemplo en una especie de mesa (si puedes soportar los operadores ser utilizado como el delimitadores de tabla)

• En las especificaciones, puede definir ejemplos que están anidados como libidum y automatically cleaned-up en todos los niveles

Ésta es sin duda una comparación muy parcial y sesgada y existen muchas otras diferencias (y las bibliotecas están todavía en evolución, ...).

Al final del día, creo que realmente depende de su estilo de prueba/especificación. Si es simple (estructura de especificación simple, configuraciones, expectativas, ...) entonces ambas bibliotecas aparecerán muy similares. De lo contrario, ambos tienen su opinión sobre cómo se deben hacer las cosas. Como último ejemplo de esto, puede echarle un vistazo al etiquetado: en ScalaTest y en specs.

Espero que esto ayude.

Answer 4

soporte IDE puede ser otro punto

I He estado tratando de hacer que Specs funcione con Eclipse a través de JUnit, y encontré que la solución oficial es un poco "hacky". Configuración de especificaciones: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

La integración de ScalaTest (también a través de JUnit) con parece un poco menos hacky. Aún así, no tengo ninguno de ellos para trabajar tan bien como JUnit y Java.

configuración ScalaTest: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

Answer 5

Si un factor de decisión es el tiempo de compilación, scalatest seems to perform better.

Actualmente estamos utilizando specs2 en nuestro proyecto, pero sufren de lento tiempos de compilación en las pruebas. Acabo de terminar un POC al mudarme a Scalatest y vi que los tiempos de compilación disminuyen en un factor de aproximadamente 0.82 simplemente al cambiar los 2 frameworks en algunas de nuestras fuentes.

Answer 6

Las principales diferencias entre ScalaTest y Specs2 son:

• La estructura global de la prueba en Specs2 es diferente a la de ScalaTest.
• Specs2 tiene un conjunto diferente de Matchers con diferente sintaxis.
• Las pruebas Specs2 están principalmente dedicadas al desarrollo impulsado por el comportamiento (BDD), mientras que las pruebas ScalaTest son más genéricas.
• ScalaTest ofrece mucha más variedad y versatilidad. Por ejemplo, para escribir BDD-como Specs2 en ScalaTest, se puede utilizar Spec, FeatureSpec, WordSpec, FlatSpec y GivenWhenThen rasgos junto con ShouldMatchers o MustMatcher. Esto le da al desarrollador más flexibilidad para seguir su propio estilo de especificaciones de escritura.

• Specs2 tiene un número significativamente mayor de Matchers que ScalaTest. La mayoría de ellos son para una necesidad particular. Por ejemplo, en Specs2, se puede decir:

  unArchivo mustbe adirectory

• Dónde Specs2 tiene comparadores individuales para java.io.Files, ScalaTest no tiene comparadores similares.

• Otra diferencia entre ScalaTest y Spec son las conversiones implícitas. ScalaTest solo tiene una conversión implícita, que logramos utilizando el operador ===. Sin embargo, esto se puede desactivar en ScalaTest usando una sola línea de código. Esta es la única conversión implícita que se obtiene de forma gratuita en ScalaTest. Hay otras conversiones implícitas, que se pueden usar mezclando otros rasgos. Contrario a esto, Specs2 le da docenas de conversiones implícitas simplemente extendiendo la clase de Especificación. En la práctica, esto no hace mucha diferencia. La única diferencia sería que el código de prueba sería más legible sin conversiones explícitas.

• Specs2 tiene tablas de datos. Esto permite el uso de varios ejemplos, que pueden conducir la prueba, al igual que las pruebas basadas en propiedades.

• Las pruebas de Specs2 difieren de las de ScalaTest ya que se pueden ejecutar simultáneamente en una secuencia separada.