Хэл Фултон - Программирование на языке Ruby

rep.report("str += ") { n.times { s2 += "x" } }

end

Здесь мы сравниваем три способа добавить символ в конец строки, дающие один и тот же результат. Чтобы можно было получить более точные цифры, каждая операция выполняется 200000 раз. Вот что вышло:

user system total real

str << 0.180000 0.000000 0.180000 ( 0.174697)

str.insert 0.200000 0.000000 0.200000 ( 0.200479)

str += 15.250000 13.120000 28.370000 (28.375998)

Обратите внимание, что последний вариант на два порядка медленнее остальных. Почему? Какой урок можно извлечь отсюда?

Вы можете предположить, что оператор +почему-то работает медленно, но дело в другом. Это единственный из трех способов, который не работает с одним и тем же объектом, а каждый раз создает новый.

Стало быть, вывод такой: создание объекта — дорогая операция. Библиотека Benchmark может преподать много подобных уроков, но я все же рекомендую сначала заняться высокоуровневым профилированием.

Метод inspect(и вызывающий его метод p) предназначен для вывода объектов в виде, понятном человеку. В этом смысле он является связующим звеном между тестированием и отладкой, поэтому рассмотрение его в этой главе оправданно.

Проблема в том, что результат, формируемый методом p, бывает трудно читать. Из-за этого и появилась библиотека pp, добавляющая одноименный метод. Рассмотрим следующий искусственный пример объекта my_obj:

class MyClass

attr_accessor :alpha, :beta, :gamma

def initialize(a,b,c)

@alpha, @beta, @gamma = a, b, с

end

end

x = MyClass.new(2, 3, 4)

y = MyClass.new(5, 6, 7)

z = MyClass.new(7, 8, 9)

my_obj = { x => y, z => [:p, :q] }

p my_obj

Вызов метода pпечатает следующее:

{#

@gamma=4>=>#,

#=>[:p, :q]}

Все правильно и в общем-то даже читаемо. Но… некрасиво. А давайте затребуем библиотеку ppи воспользуемся предоставляемым ей методом pp:

require 'pp'

# ...

pp my_obj

Теперь вывод приобретает такой вид:

{#=>[:p, :q],

#=>

#}

Мы получили хотя бы пробелы и разбиение на строки. Уже лучше. Но можно пойти еще дальше. Предположим, что в классе MyClassопределен специальный метод pretty_print:

class MyClass

def pretty_print(printer)

printer.text "MyClass(#@alpha, #@beta, #@gamma)"

end

end

Аргумент printer передается вызывающей программой (или методом pp). Это аккумулятор текста, являющийся экземпляром класса PP; мы вызываем его метод textи передаем ему текстовое представление self. Вот что получается в результате:

{MyClass(7, 8, 9)=>[:p, :q] , MyClass(2, 3, 4)=>MyClass(5, 6, 7)}

Разумеется, можно настроить поведение по своему вкусу. Можно, например, печатать переменные экземпляра на разных строчках с отступами.

На самом деле в библиотеке ppесть много средств для подготовки ваших классов к совместной работе с методом pp. Методы object_group, seplist, breakableи прочие позволяют управлять расстановкой запятых, разбиением на строки и другими способами форматирования. Дополнительную информацию можно найти в документации на сайте http://ruby-doc.org.

В этой главе мы рассмотрели некоторые подходы к тестированию (преимущественно, к автономному тестированию компонентов). Мы познакомились с библиотекой Test::Unitи комплектом инструментов ZenTest.

Мы бросили беглый взгляд на отладчик Ruby, а также показали, как с помощью библиотеки ruby-breakpointможно переходить в интерактивную оболочку irbдля проведения сеанса отладки.

Мы рассмотрели инструмент для анализа покрытия кода rcovи обсудили, для чего могут понадобиться такие измерения. Наконец, остановились на профилировании и замере временных характеристик программы на Ruby.

Предположим, что вы работаете над программой, которую собираетесь предложить обществу. Что вы делаете по завершении тестирования? Пришло время задуматься над оформлением дистрибутивного пакета и способами его распространения. Этим мы и займемся в следующей главе.

Эта глава посвящена вопросу о том, как проявлять уважение к конечному пользователю своей программы. Если у вас конечного пользователя нет или вы не хотите казаться вежливым, можете пропустить ее.

Есть две вещи, о которых типичный программист не желает задумываться: документация и процедура установки. Ниже я попытаюсь убедить вас не пугаться ни того, ни другого. Нашлись люди, приложившие максимум усилий к написанию библиотек и инструментов, упрощающих решение этих задач.

Однако данная глава оказалась короткой. Дополнительную информацию о затронутых в ней темах можете почерпнуть, изучая сделанное другими.

Один из самых замечательных имеющихся инструментов — программа RDoc, написанная Дэйвом Томасом. С нее и начнем.

RDoc— не единственный инструмент документирования для Ruby: его предшественником является программа RDTOOL. Но во многих отношениях RDocпревосходит своих конкурентов; к тому же он наиболее распространенный, по крайней мере, в США.

Замечательной особенностью RDocявляется то, что он пытается вывести нечто полезное, даже если в исходном тексте вообще нет комментариев. Для этого он анализирует текст программы и собирает информацию обо всех классах, модулях, константах, методах и т.д.

Тем самым вы можете получить более или менее полезный HTML-файл из исходного текста, не содержащего никакой внутренней документации. Если раньше не пробовали, попробуйте сейчас.

Но это еще не все. RDocтакже пытается ассоциировать найденные комментарии с конкретными частями программы. Общее правило таково: блочный комментарий, предшествующий определению (скажем, класса или метода), считается описанием этого определения.

Если просто вызвать RDocдля какого-нибудь исходного текста на Ruby, будет создан каталог doc, в который помещаются все выходные файлы (этот стандартный шаблон уже неплох, но есть и другие). Откройте в браузере файл index.html и изучите его.

В листинге 17.1 приведен простой (почти ничего не содержащий) исходный файл. Все определенные в нем методы пусты. Но RDocдаже в таком случае формирует симпатичную страницу документации (рис. 17.1).

require ' foo'

# Внешний класс MyClass.

class MyClass

CONST = 237

# Внутренний класс MyClass::Alpha...