RSpec vs Test :: Unidad en rieles

13

Nunca he estado realmente convencido de las ventajas que obtienes al cambiar a RSpec desde Test :: Unit en Ruby on Rails (a pesar de leer de vez en cuando sobre RSpec).

¿Qué hay en RSpec que la mayoría de los proyectos de Rails parecen estar usando?

(algunos ejemplos de código que indican claramente las ventajas de uno sobre el otro serían muy apreciados)

    
pregunta Paweł Gościcki 17.12.2010 - 11:38

2 respuestas

11

Es en gran medida una cuestión de gustos, y la mayoría de las herramientas de prueba merecen su apoyo a ambos. Mi preferencia personal es para RSpec sobre prueba :: Unidad porque a) la salida y el diseño de las pruebas se centran en lo que se supone que debe hacer el objeto bajo prueba (a diferencia de lo que es el código) yb) diciendo "X debería Y" tiene más sentido para mí que "afirmar que el predicado X es X.

Para brindarle un poco de contexto para los puntos anteriores, aquí tiene una comparación (bastante artificial) del código de salida / fuente de dos pruebas de unidades funcionalmente equivalentes, una escrita con RSpec y la otra con Test :: Unit.

Código en prueba

class DeadError < StandardError; end

class Dog
  def bark
    raise DeadError.new "Can't bark when dead" if @dead
    "woof"
  end

  def die
    @dead = true
  end
end

Prueba :: Unidad

 require 'test/unit'
  require 'dog'

  class DogTest < Test::Unit::TestCase
    def setup
      @dog = Dog.new
    end

    def test_barks
      assert_equal "woof", @dog.bark    
    end

    def test_doesnt_bark_when_dead
      @dog.die
      assert_raises DeadError do
        @dog.bark
      end
    end
  end

RSpec

require 'rspec'
require 'dog'

describe Dog do
  before(:all) do
    @dog = Dog.new
  end

  context "when alive" do
    it "barks" do
      @dog.bark.should == "woof"
    end
  end

  context "when dead" do
    before do
      @dog.die
    end

    it "raises an error when asked to bark" do
      lambda { @dog.bark }.should raise_error(DeadError)
    end
  end
end

Prueba :: Unidad de salida (tan completa como podría hacerlo)

Ξ code/examples → ruby dog_test.rb --verbose
Loaded suite dog_test
Started
test_barks(DogTest): .
test_doesnt_bark_when_dead(DogTest): .

Finished in 0.004937 seconds.

Salida de RSpec (formateador de documentación)

Ξ code/examples → rspec -fd dog_spec.rb 

Dog
  when alive
    barks
  when dead
    raises an error when asked to bark

Finished in 0.00224 seconds
2 examples, 0 failures

2 tests, 2 assertions, 0 failures, 0 errors

P.S. Creo que Berin (respondedor anterior) está combinando los roles de Pepino (que surgió del proyecto RSpec pero es independiente) y RSpec. Cucumber es una herramienta para las pruebas de aceptación automatizadas en un estilo BDD, mientras que RSpec es una biblioteca de códigos para las pruebas que pueden ser, y se utilizan, a nivel de unidad, integración y funcional. Por lo tanto, el uso de RSpec no excluye las pruebas unitarias, es solo que usted llama 'especificaciones' a sus pruebas unitarias.

    
respondido por el Mortice 17.12.2010 - 15:50
2

Últimamente parece que Cucumber ha estado recibiendo más apoyo en la comunidad de Rails. Aquí está el argumento resumido que escuché en una entrevista con el líder de RSpec (de un antiguo Podcast de Ruby on Rails).

En la comunidad ágil (en ese momento) hubo un gran impulso para el desarrollo guiado por pruebas con el énfasis en probar primero para demostrar que tenía que cambiar algo. Había algo filosóficamente mal con eso. En esencia, las pruebas son una forma de verificar que su implementación es correcta, entonces, ¿cómo piensa de manera diferente acerca del diseño de conducción? La ventaja de RSpec supuso que usted especificó primero, y ¿no sería genial si la especificación también verificara los resultados de su implementación?

El simple cambio de nombre assert a should ayuda a enfocar la mente en la forma correcta de escribir especificaciones y pensar sobre el diseño. Sin embargo, eso es solo una parte de la ecuación.

Más importante aún, dado que muchos creyentes de TDD afirmaban que las pruebas documentaban el diseño, la mayoría de la documentación era deficiente. Las pruebas son bastante opacas para los no desarrolladores que no están familiarizados con el lenguaje. Incluso entonces, el diseño no es inmediatamente evidente al leer la mayoría de las pruebas.

Como objetivo secundario, RSpec ideó una forma de generar documentación escrita a partir de las especificaciones. Es esta especificación escrita que le da a RSpec una ventaja sobre la sencilla Prueba :: Unidad para impulsar el diseño de una aplicación. ¿Por qué escribir algo más de una vez cuando puedes documentar y verificar la consistencia del diseño al mismo tiempo?

Tengo entendido que Cucumber, que tuvo el beneficio de venir más tarde y aprender las lecciones de RSpec, hace un mejor trabajo de este objetivo secundario sin perder el objetivo principal (capacidad de probar la implementación a partir de la especificación). Pepino hace esto con una API bastante parecida al inglés que los no programadores pueden asimilar razonablemente. Es posible que necesiten ayuda de los programadores para completar algunas definiciones de nuevos métodos de verificación, pero está diseñado para ser extensible.

La conclusión es que RSpec / Cucumber no debe reemplazar la prueba de la unidad por completo. Es posible que se adapten mejor a la documentación y verificación de su diseño, pero todavía hay que realizar varias pruebas de implementación, especialmente con errores sutiles que se derivan de la implementación y no del diseño de la aplicación. Sin embargo, reduce la cantidad de pruebas que tienes que escribir.

    
respondido por el Berin Loritsch 17.12.2010 - 14:17

Lea otras preguntas en las etiquetas

Comentarios Recientes

4 "React probablemente todavía verá mucho uso en Angular 2 solo en este punto. Sin embargo, hay algunos conceptos nuevos que hemos experimentado trabajando con Meteor en los últimos 4 meses que hacen pruebas con react y React Native mucho más fácil y en 3 parters, difícil ". Max: "Cosas como errores que se acumulan hasta la cantidad de fallas (tal vez 1000/1000 solo es increíblemente tentador), o obtener errores tipográficos en todo el código parece ser relativamente poco común y más fácil de enfrentar durante... Lee mas