Еще немного фона было бы полезно. Я не могу сказать, что понимаю поведение, которое вы видите.
Я использую как базовую тестовую/модульную библиотеку, которая поставляется с ruby 1.8, так и несколько версий gem с ruby 1.9. Нормальным поведением для обоих из них является запуск всего загруженного пакета до завершения и суммирование результатов.
Запуск сценария, который говорит require 'test/unit'
, добавит хук на выходе для запуска Test::Unit::AutoRunner
с коллектором Test::Unit::Collector::ObjectSpace
(т. е. запускает каждый экземпляр Test::Unit::TestCase
, загруженный в настоящее время в глобальном объектном пространстве).
Также довольно легко написать свой собственный тестовый бегун, который вручную загружает ваши тестовые классы и упаковывает их в Test::Unit::TestSuite
, а также фиксирует его результаты.
Но с каждой версией теста/модуля, которую я использовал, я всегда видел завершение всего набора и сообщал как о сбоях, так и об ошибках. Вместо дополнительной информации я бы предложил поэкспериментировать с одним фиктивным тестом, чтобы посмотреть, как вы должны ожидать, что тест/модуль будет вести себя.
Например
require 'test/unit'
class Foo < Test::Unit::TestCase
def testFoo
flunk 'bad foo'
end
end
class Bar < Test::Unit::TestCase
def testBar
raise 'bar bar'
end
end
дает
Loaded suite foo
Started EF Finished in 0.001000 seconds.
1) Error:
testBar(Bar)
RuntimeError: bad bar
foo.rb:9:in `testBar`
2) Failure:
testFoo(Foo) [foo.rb:4]:
bad foo
2 tests, 1 assertions, 1 failures, 1 errors, 0 skips
Наконец: где вы пытаетесь спасти/обеспечить? В методах испытаний? В обычных обстоятельствах нет причин перехватывать AssertionFailedError. Это Test::Unit::TestCase
для подсчета ошибок и предоставления вам нужного отчета. Улавливание этого мешает написанию теста/модуля.
person
Ryan Calhoun
schedule
15.11.2010