spec - ¿Cuál es la mejor manera de probar la unidad de métodos protegidos y privados en Ruby?

pruebas unitarias ruby

Question

¿Cuál es la mejor manera de probar las unidades de métodos protegidos y privados en Ruby, utilizando el marco estándar de Ruby Test::Unit ?

Estoy seguro de que alguien insistirá y dirá dogmáticamente que "usted solo debe probar los métodos públicos de la unidad, si necesita pruebas unitarias, no debe ser un método privado o protegido", pero no estoy realmente interesado en debatir eso. Tengo varios métodos que están protegidos o son privados por buenas y válidas razones, estos métodos privados / protegidos son moderadamente complejos, y los métodos públicos de la clase dependen de que estos métodos protegidos / privados funcionen correctamente, por lo tanto, necesito una forma de probarlos. los métodos protegidos / privados.

Una cosa más ... Generalmente pongo todos los métodos para una clase dada en un archivo, y la unidad prueba para esa clase en otro archivo. Idealmente, me gustaría que toda la magia implementara esta funcionalidad de "prueba unitaria de métodos privados y protegidos" en el archivo de prueba de la unidad, no en el archivo fuente principal, a fin de mantener el archivo fuente principal lo más simple y directo posible.

Answer 1

Estoy seguro de que alguien insistirá y dirá dogmáticamente que "usted solo debe probar los métodos públicos de la unidad, si necesita pruebas unitarias, no debe ser un método privado o protegido", pero no estoy realmente interesado en debatir eso.

También podría refactorizarlos en un nuevo objeto en el que esos métodos sean públicos y delegarlos de forma privada en la clase original. Esto le permitirá probar los métodos sin metaruby mágico en sus especificaciones sin dejar de mantenerlos privados.

Tengo varios métodos que están protegidos o privados por buenas y válidas razones

¿Cuáles son esas razones válidas? Otros lenguajes OOP pueden escaparse sin métodos privados en absoluto (Smalltalk viene a la mente, donde los métodos privados solo existen como una convención).

Answer 2

Aquí hay una adición general a Class que uso. Es un poco más inteligente que solo hacer público el método que estás probando, pero en la mayoría de los casos no importa, y es mucho más legible.

class Class
def publicize_methods
saved_private_instance_methods = self.private_instance_methods
self.class_eval { public *saved_private_instance_methods }
begin
yield
ensure
self.class_eval { private *saved_private_instance_methods }
end
end
end
MyClass.publicize_methods do
assert_equal 10, MyClass.new.secret_private_method
end

El uso de enviar para acceder a métodos protegidos / privados está roto en 1.9, por lo que no es una solución recomendada.

Answer 3

Aquí hay una manera fácil si usa RSpec:

before(:each) do
MyClass.send(:public, *MyClass.protected_instance_methods)
end

Answer 4

En Test :: unidad marco puede escribir,

MyClass.send(:public, :method_name)

Aquí "method_name" es un método privado.

y mientras llamas a este método puedes escribir,

assert_equal expected, MyClass.instance.method_name(params)

Answer 5

En lugar de obj.send puedes usar un método singleton. Son 3 líneas más de código en su clase de prueba y no requiere cambios en el código real para ser probado.

def obj.my_private_method_publicly (*args)
my_private_method(*args)
end

En los casos de prueba, entonces usa my_private_method_publicly siempre que quiera probar my_private_method .

http://mathandprogramming.blogspot.com/2010/01/ruby-testing-private-methods.html

obj.send para métodos privados fue reemplazado por send! en 1.9, pero luego send! fue eliminado de nuevo. Entonces obj.send funciona perfectamente bien.

Answer 6

Para corregir la respuesta superior anterior: en Ruby 1.9.1, es Object # send que envía todos los mensajes, y Object # public_send que respeta la privacidad.

Answer 7

Para hacer esto:

disrespect_privacy @object do |p|
assert p.private_method
end

Puede implementar esto en su archivo test_helper:

class ActiveSupport::TestCase
def disrespect_privacy(object_or_class, &block) # access private methods in a block
raise ArgumentError, ''Block must be specified'' unless block_given?
yield Disrespect.new(object_or_class)
end
class Disrespect
def initialize(object_or_class)
@object = object_or_class
end
def method_missing(method, *args)
@object.send(method, *args)
end
end
end

Answer 8

Para hacer público todo el método protegido y privado para la clase descrita, puede agregar lo siguiente a su spec_helper.rb y no tener que tocar ninguno de sus archivos de especificaciones.

RSpec.configure do |config|
config.before(:each) do
described_class.send(:public, *described_class.protected_instance_methods)
described_class.send(:public, *described_class.private_instance_methods)
end
end

Answer 9

Probablemente me inclinaría hacia el uso de instance_eval (). Sin embargo, antes de saber sobre instance_eval (), crearía una clase derivada en mi archivo de prueba de unidad. Luego establecería los métodos privados para que sean públicos.

En el siguiente ejemplo, el método build_year_range es privado en la clase PublicationSearch :: ISIQuery. Obtener una nueva clase solo para fines de prueba me permite configurar un método para que sea público y, por lo tanto, directamente comprobable. Del mismo modo, la clase derivada expone una variable de instancia llamada ''resultado'' que anteriormente no estaba expuesta.

# A derived class useful for testing.
class MockISIQuery < PublicationSearch::ISIQuery
attr_accessor :result
public :build_year_range
end

En mi prueba unitaria tengo un caso de prueba que ejemplifica la clase MockISIQuery y prueba directamente el método build_year_range ().

Answer 10

Puede "reabrir" la clase y proporcionar un nuevo método que delegue en la clase privada:

class Foo
private
def bar; puts "Oi! how did you reach me??"; end
end
# and then
class Foo
def ah_hah; bar; end
end
# then
Foo.new.ah_hah

Answer 11

Puede omitir la encapsulación con el método de envío:

myobject.send(:method_name, args)

Esta es una ''característica'' de Ruby. :)

¡Hubo un debate interno durante el desarrollo de Ruby 1.9 que consideró send privacidad del respeto y send! ignóralo, pero al final nada cambió en Ruby 1.9. Ignora los comentarios a continuación discutiendo send! y rompiendo cosas

Answer 12

Sé que llego tarde a la fiesta, pero no pruebo métodos privados ... No puedo pensar en una razón para hacer esto. Un método de acceso público es usar ese método privado en alguna parte, probar el método público y la variedad de escenarios que causarían que se use ese método privado. Algo entra, sale algo. Probar métodos privados es un gran no-no, y hace que sea mucho más difícil refactorizar tu código más tarde. Son privados por una razón.

Answer 13

Similar a la respuesta de @ WillSargent, esto es lo que he usado en un bloque de describe para el caso especial de probar algunos validadores protegidos sin tener que pasar por el proceso pesado de creación / actualización con FactoryGirl (y podría usar private_instance_methods manera similar):

 describe "protected custom `validates` methods" do
# Test these methods directly to avoid needing FactoryGirl.create
# to trigger before_create, etc.
before(:all) do
@protected_methods = MyClass.protected_instance_methods
MyClass.send(:public, *@protected_methods)
end
after(:all) do
MyClass.send(:protected, *@protected_methods)
@protected_methods = nil
end
# ...do some tests...
end

Answer 14

Simplemente vuelva a abrir la clase en su archivo de prueba y redefina el método o los métodos como públicos. No tiene que redefinir las agallas del método en sí, simplemente pase el símbolo a la llamada public .

Si tu clase original se define así:

class MyClass
private
def foo
true
end
end

En su archivo de prueba, solo haga algo como esto:

class MyClass
public :foo
end

Puede pasar múltiples símbolos a public si quiere exponer más métodos privados.

public :foo, :bar

Answer 15

Una forma en que lo hice en el pasado es:

class foo
def public_method
private_method
end
private unless ''test'' == Rails.env
def private_method
''private''
end
end

Answer 16

instance_eval() podría ayudar:

--------------------------------------------------- Object#instance_eval
obj.instance_eval(string [, filename [, lineno]] ) => obj
obj.instance_eval {| | block } => obj
------------------------------------------------------------------------
Evaluates a string containing Ruby source code, or the given
block, within the context of the receiver (obj). In order to set
the context, the variable self is set to obj while the code is
executing, giving the code access to obj''s instance variables. In
the version of instance_eval that takes a String, the optional
second and third parameters supply a filename and starting line
number that are used when reporting compilation errors.
class Klass
def initialize
@secret = 99
end
end
k = Klass.new
k.instance_eval { @secret } #=> 99

Puede usarlo para acceder a métodos privados y variables de instancia directamente.

También podría considerar el uso de send() , que también le dará acceso a métodos privados y protegidos (como sugirió James Baker)

Alternativamente, podría modificar la metaclase de su objeto de prueba para hacer que los métodos privados / protegidos sean públicos solo para ese objeto.

 test_obj.a_private_method(...) #=> raises NoMethodError
test_obj.a_protected_method(...) #=> raises NoMethodError
class << test_obj
public :a_private_method, :a_protected_method
end
test_obj.a_private_method(...) # executes
test_obj.a_protected_method(...) # executes
other_test_obj = test.obj.class.new
other_test_obj.a_private_method(...) #=> raises NoMethodError
other_test_obj.a_protected_method(...) #=> raises NoMethodError

Esto le permitirá llamar a estos métodos sin afectar a otros objetos de esa clase. Puede volver a abrir la clase dentro de su directorio de prueba y hacerla pública para todas las instancias dentro de su código de prueba, pero eso podría afectar su prueba de la interfaz pública.