ruby - practices - Rspec: espera frente a espera con bloque, ¿cuál es la diferencia?

rspec capybara best practices

Question

Simplemente aprendiendo la sintaxis de rspec y noté que este código funciona:

  context "given a bad list of players" do
    let(:bad_players) { {} }

    it "fails to create given a bad player list" do
       expect{ Team.new("Random", bad_players) }.to raise_error
     end 
  end

Pero este código no lo hace:

  context "given a bad list of players" do
    let(:bad_players) { {} }

    it "fails to create given a bad player list" do
       expect( Team.new("Random", bad_players) ).to raise_error
     end 
  end

Me da este error:

Team given a bad list of players fails to create given a bad player list
     Failure/Error: expect( Team.new("Random", bad_players) ).to raise_error
     Exception:
       Exception
     # ./lib/team.rb:6:in `initialize''
     # ./spec/team_spec.rb:23:in `new''
     # ./spec/team_spec.rb:23:in `block (3 levels) in <top (required)>''

Mi pregunta es:

1. ¿Por qué pasó esto?
2. ¿Cuál es la diferencia entre el ejemplo anterior y el anterior exactamente en ruby?

También estoy buscando reglas sobre cuándo usar una sobre la otra.

Un ejemplo más de los mismos resultados, pero inversos, donde funciona este código:

  it "has a list of players" do
    expect(Team.new("Random").players).to be_kind_of Array
  end 

Pero este código falla

  it "has a list of players" do
    expect{ Team.new("Random").players }.to be_kind_of Array
  end

El error que recibo en este caso es:

Failure/Error: expect{ Team.new("Random").players }.to be_kind_of Array
       expected #<Proc:0x007fbbbab29580@/Users/amiterandole/Documents/current/ruby_sandbox/tdd-ruby/spec/team_spec.rb:9> to be a kind of Array
     # ./spec/team_spec.rb:9:in `block (2 levels) in <top (required)>''

La clase que estoy probando se ve así:

class Team
  attr_reader :name, :players

  def initialize(name, players = [])
    raise Exception unless players.is_a? Array

    @name = name
    @players = players
  end
end

Answer 1

Como se ha mencionado:

expect(4).to eq(4)

Esto es específicamente probar el valor que ha enviado como parámetro al método. Cuando intentas probar errores planteados cuando haces lo mismo:

expect(raise "fail!").to raise_error

Su argumento se evalúa de inmediato y esa excepción se lanzará y su prueba explotará allí mismo.

Sin embargo, cuando usa un bloque (y esto es ruby ​​básico), el contenido del bloque no se ejecuta inmediatamente; su ejecución está determinada por el método que está llamando (en este caso, el método de expect controla cuándo ejecutar su bloque) :

expect{raise "fail!"}.to raise_error

Podemos ver un método de ejemplo que podría manejar este comportamiento:

def expect(val=nil)
  if block_given?
    begin
      yield
    rescue
      puts "Your block raised an error!"
    end
  else
    puts "The value under test is #{val}"
  end
end

Aquí puede ver que es el método de expect que está rescatando manualmente su error para que pueda probar si los errores se yield o no, etc. el yield es la forma en que un método ruby ​​de ejecutar cualquier bloque se le pasó al método.

Answer 2

En el primer caso, cuando pasa un bloque a expect , la ejecución del bloque no se produce hasta que llega el momento de evaluar el resultado, momento en el que el código RSpec puede detectar cualquier error que se genere y compararlo con la expectativa.

En el segundo caso, el error surge cuando se evalúa el argumento a expect , por lo expect código de expect no tiene oportunidad de involucrarse.

En cuanto a las reglas, pasa un bloque o un Proc si está tratando de probar el comportamiento (por ejemplo, aumentar errores, cambiar algún valor). De lo contrario, pasa un argumento "convencional", en cuyo caso el valor de ese argumento es lo que se prueba.