Me estoy haciendo cargo de un código de Ruby que incluye un conjunto de pruebas bastante grande. Una cosa que faltaba y que estoy agregando es rubocop para solucionar algunos problemas. Una cosa que he notado es que se han configurado numerosas pruebas para que se generen dinámicamente de esta manera:
describe 'some test' do SOME_CONSTANT = { some hash } SOME_CONSTANT.each do |param1, param2| it 'does #{param1} and successfully checks #{param2} do # do something with #{param1} or #{param2} expect(param2).to eq "blahblah" end end end El problema aquí es SOME_CONSTANT . Con rubocop esto falla la regla cop RSpec/LeakyConstantDeclaration . La forma en que se configuran estas pruebas, estas constantes pueden reasignar una constante global por accidente y provocar fallas aleatorias en las especificaciones en otros lugares si la gente no está prestando atención.
La única solución viable que he encontrado es cambiar estas constantes en variables de instancia . Por ejemplo:
describe 'some test' do @some_constant = { some hash } @some_constant.each do |param1, param2| it 'does #{param1} and successfully checks #{param2} do # do something with #{param1} or #{param2} expect(param2).to eq "blahblah" end end end Existe el peligro de que estas variables de instancia también se filtren en otras especificaciones de ti/ejemplo (dentro del mismo archivo de especificaciones si una sola prueba lo cambia), pero al menos se limita a los archivos individuales *_spec.rb y no afectará alcance global de todo el conjunto de pruebas. Esto también corrige RSpec/LeakyConstantDeclaration .
¿Alguien tiene alguna sugerencia mejor? ¿Uno que no usa variables de instancia y es más moderno compatible con RSpec? ¡He intentado usar let y let! pero la forma en que se configuran las pruebas, cualquier variable configurada de esta manera solo it accesible dentro de los bloques. También intenté usar stub_const en un bloque before(:context) , pero me encontré con el mismo problema en el que solo se puede acceder a la constante stubbed dentro del contexto it / example . Incluso probé RSpec.Mocks.with_temporary_scope y el mismo problema. Las variables de instancia parecen ser lo único que funciona en esta configuración.
¡Gracias de antemano por cualquier sugerencia útil!
El ejemplo que proporcionó se parece demasiado a la programación, en lugar de una prueba; por ejemplo, trataría de ser un poco más explícito en lugar de agregar un bucle de comportamientos.
Dos construcciones vienen a la mente:
let (que sé que dijiste que hiciste), pero con anidamiento adicional. IIRC, es posible que pueda agregar otro bloque de describe fuera de each bloque describe 'my test' do shared_examples 'does the thing' do |arg1, arg2| before { arg1.call } it "does #{arg1} and returns #{arg2}" do expect(arg2).to eq(true) end end it_behaves_like 'does the thing', Foo.new, bar it_behaves_like 'does the thing', Blarge.new, blah endTambién puede combinarlos con let y/o un bloque (y refactorizar el ejemplo compartido para hacer referencia a estos en lugar de pasar los argumentos explícitamente
it_behaves_like 'does the thing' do let(:method) { :foo } let(:result) { 42 } endDe acuerdo con Jay, trato de alejarme de las pruebas dinámicas y prefiero hacerlas más simples y explícitas (aunque más repetitivas). Sin embargo, eso puede ser más un refactor de lo que está buscando asumir. Para abordar solo el problema de los nombres de las variables, consideraría no asignar los datos a una variable, por ejemplo:
[:each, :attribute, :to, :test].each do |attr| it "does a thing with #{attr}"... endy si es una matriz/hash más grande:
{ some larger hash }.each do |param1, param2| it 'does #{param1} and successfully checks #{param2}' do # do something with #{param1} or #{param2} expect(param2).to eq "blahblah" end end