Книга: Программирование на языке Ruby

16.1. Библиотека Test::Unit

16.1. Библиотека Test::Unit

«Стандартный» способ автономного тестирования компонентов в Ruby — библиотека Test::Unit Натаниэля Тэлбота (Nathaniel Talbott). Она была включена в дистрибутив Ruby еще в 2001 году.

В этой библиотеке для анализа тестового кода применяется отражение. Когда вы создаете подкласс класса Test::Unit::TestCase, все методы, имена которых начинаются с test, считаются тестовыми.

require 'test/unit'
class TC_MyTest < Test::Unit::TestCase
 def test_001
  # ...
 end
 def test_002
  # ...
 end
 # ...
end

Методы необязательно нумеровать, как показано в этом примере. Это мое личное соглашение, но, конечно, есть и другие.

Нежелательно и, пожалуй, даже неправильно составлять тесты так, чтобы их поведение зависело от порядка запуска. Однако Test::Unit прогоняет их в алфавитном (лексикографическом) порядке, поэтому, нумеруя свои методы, я вижу, как они выполняются в определенной последовательности.

Я также предпочитаю включать некий «заголовок» в имя метода (описывающий его область действия или назначение):

def test_053_default_to_current_directory
 # ...
end
def test_054_use_specified_directory
 # ...
end

Кроме прочего, неплохо оставлять хотя бы однострочный комментарий, касающийся цели и смысла теста. Вообще говоря, у каждого теста должна быть только одна цель.

А если нужно организовать некую среду выполнения, для чего требуется время? Неразумно делать это для каждого теста, и мы не вправе завести для данной цели отдельный метод (поскольку поведение не должно зависеть от порядка прогона).

Если всем тестам нужна особая среда, можно воспользоваться методами класса setup и teardown. Возможно, вам это покажется странным, но вызываются они для каждого теста. Если вы хотите выполнить настройку один раз, перед прогоном одного конкретного или всех тестов, то можете поместить соответствующий код в тело класса раньше всех тестовых методов (или даже до самого класса).

А если после выполнения всех тестов нужно разрушить созданную среду? По техническим причинам (так уж работает библиотека Test::Unit) сделать это трудно. «Самый лучший» способ — переопределить метод run всего комплекта тестов (но не метод класса run), обернув его функциональность. Рассмотрим пример в листинге 16.1.

require 'test/unit'
class MyTest < Test::Unit::TestCase
 def self.major_setup
  # ...
 end
 def self.major_teardown
  # ...
 end
 def self.suite
  mysuite = super        # Вызвать метод suite родителя.
  def mysuite.run(*args) # Добавить синглетный метод
   MyTest.major_setup
   super
   MyTest.major_teardown
  end
  mysuite                # и вернуть новое значение.
 end
 def setup
  # ...
 end
 def teardown
  # ...
 end
 def test_001
  # ...
 end
 def test_002
  # ...
 end
 # ...
end

Вряд ли вы будете поступать так часто. О методе suite мы поговорим чуть позже, а пока продолжим рассмотрение отдельных тестов.

Что должно входить в тест? Нужно как-то решить, прошел он или нет. Для этой цели применяются утверждения.

Простейшее утверждение — это метод assert. Он принимает проверяемый параметр и еще один необязательный параметр (сообщение). Если значение параметра истинно (то есть все, кроме false и nil), тест прошел. В противном случае тест не прошел — тогда печатается сообщение, если оно было задано.

Есть и другие методы для формулирования утверждений. Обратите внимание, что «ожидаемое» значение всегда предшествует «фактическому».

assert_equal(expected, actual)     # assert(expected==actual)
assert_not_equal(expected, actual) # assert(expected!=actual)
assert_match(regex, string)        # assert(regex =~ string)
assert_no_match(regex, string)     # assert(regex string)
assert_nil(object)                 # assert(object.nil?)
assert_not_nil(object)             # assert(!object.nil?)

Некоторые утверждения носят более объектно-ориентированный характер:

assert_instance_of(klass, obj) # assert(obj.instance_of? klass)
assert_kind_of(klass, obj)     # assert(obj.kind_of? klass)
assert_respond_to(obj, meth)   # assert(obj.respond_to? meth)

Другие относятся к исключениям и символам, которые генерируются методом throw. Понятно, что такие методы принимают блок.

assert_nothing_thrown { ... }    # Не было throw.
assert_nothing_raised { ... }    # Не было raise.
assert_throws(symbol) { ... }    # Символ в результате throw.
assert_raises(exception) { ... } # Исключение в результате raise.

Есть еще несколько утверждений, но эти применяются чаще всего и отвечают почти всем потребностям. Дополнительную информацию можно найти в онлайновой документации на сайте http://ruby-doc.org.

Имеется еще метод flunk, который всегда завершается неудачно. Можно считать, что это некий вид заглушки.

Если при запуске тестового файла вы ничего специально не указываете, то по умолчанию вызывается консольный исполнитель тестов. Это возвращает нас к старой доброй технологии 1970-х годов. Имеются и другие исполнители, например графический Test::Unit::UI::GTK::TestRunner. Любой исполнитель тестов можно вызвать, обратившись к его методу run, которому передается специальный параметр, описывающий набор тестов:

class MyTests < Test::Unit::TestCase
 # ...
end
# Явное указание исполнителя тестов...
runner = Test::Unit::UI::Console::TestRunner
runner.run(MyTests)

Параметром может быть любой объект, обладающий методом suite, который возвращает объект, представляющий комплект тестов. Что все это означает?

Познакомимся к понятием комплекта тестов ближе. Оказывается, комплект тестов может состоять из набора тестов или набора подкомплектов. Следовательно, можно сгруппировать тесты так, что будет прогоняться либо только один набор, либо сразу все.

Пусть, например, есть три набора тестов, и вы хотите прогнать их как единый комплект. Можно было бы поступить так:

require 'test/unit/testsuite'
require 'tc_set1'
require 'tc_set2'
require 'ts_set3'
class TS_MyTests
 def self.suite
  mysuite = Test::Unit::TestSuite.new
  mysuite << TC_Set1.suite
  mysuite << TC_Set2.suite
  mysuite << TS_Set3.suite
  return mysuite
 end
end
Test::Unit::UI::Console::TestRunner.run(TS_MyTests)

Но такая сложность ни к чему. Имея отдельные наборы тестов, библиотека Test::Unit в состоянии просмотреть пространство объектов и объединить их все в один комплект. Поэтому следующий код тоже будет работать (и даже вызывать подразумеваемый по умолчанию исполнитель тестов):

require 'test/unit'
require 'tc_set1'
require 'tc_set2'
require 'ts_set3'

Библиотека Test::Unit располагает и другими возможностями, а в дальнейшем, вероятно, будет усовершенствована. Самую свежую информацию ищите в сети.

Оглавление книги