Często podczas pisania testów/specyfikacji mamy ochotę na przetestowanie danej metody prywatnej. Wiele osób testuje tylko publiczny interfejs klasy ale zdarzają się przypadki kiedy chciałoby się przetestować kilka wybranych prywatnych metod (np. kiedy publiczny interfejs jest bardzo prosty a prawdziwa praca wykonywana jest przez prywatne metody - co często z drugiej strony jest oznaką niezrównoważonego projektu klasy).
Z pomocą przychodzi Ruby ze swoimi mechanizmami refleksji i dynamicznych otwartych klas:
[code=ruby]require ‘rubygems’
require ‘dust’
require ‘test/unit’
class Ninja
private
def kill(num_victims)
“#{num_victims} victims are no longer with us.”
end
end
class Class
def publicize_methods
saved_private_instance_methods = self.private_instance_methods
self.class_eval { public *saved_private_instance_methods }
yield
self.class_eval { private *saved_private_instance_methods }
end
end
unit_tests do
test “kill returns a murder string” do
Ninja.publicize_methods do
assert_equal ‘3 victims are no longer with us.’, Ninja.new.kill(3)
end
end
end[/code]
Znalezione tutaj
Jeszcze raz zapytam - po co jakaś metoda jest oznaczana jako prywatna? Bo zawiera szczegóły implementacyjne, które są najbardziej podatne na zmiany, ponadto może przyjmować założenia, których nie można przekazać jako parametrów jej wywołania (np. wartości określonych zmiennych instancyjnych, wywołanie w ramach transakcji, sekcji krytycznej, przy dostępności określonego zasobu, etc.)
W RSpec jest zdaje się coś takiego jak Matcher, który pozwala nam definiować własne, czytelne nazwy metod. Wszystko pięknie, do momentu, w którym rozważymy błąd w naszej implementacji Matchera. Czy mamy go też testować (testować własne narzędzia do testowania, to już obłęd)?