Программирование на языке Ruby
Программирование на языке Ruby читать книгу онлайн
Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала
В 1990 году в сообществе программистов стала распространяться «культура тестирования». Идеи экстремального программирования и управляемой тестами разработки начали овладевать умами разработчиков по всему миру.
Являетесь ли вы твердокаменным приверженцем идеологии «тестируй с самого начала», не так существенно. Важно, что любой человек может воспользоваться инструментами, которые позволяют автоматизировать тестирование, упростив написание и прогон тестов.
Такие инструменты, как
Test::UnitПомимо этих инструментов в Ruby есть еще немало программ и библиотек для отладки, профилирования и испытания различных путей исполнения. Эта глава посвящена обзору имеющихся средств.
16.1. Библиотека Test::Unit
«Стандартный» способ автономного тестирования компонентов в Ruby — библиотека
Test::UnitВ этой библиотеке для анализа тестового кода применяется отражение. Когда вы создаете подкласс класса
Test::Unit::TestCasetestrequire '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 # ...enddef test_054_use_specified_directory # ...endКроме прочего, неплохо оставлять хотя бы однострочный комментарий, касающийся цели и смысла теста. Вообще говоря, у каждого теста должна быть только одна цель.
А если нужно организовать некую среду выполнения, для чего требуется время? Неразумно делать это для каждого теста, и мы не вправе завести для данной цели отдельный метод (поскольку поведение не должно зависеть от порядка прогона).
Если всем тестам нужна особая среда, можно воспользоваться методами класса
setupteardownА если после выполнения всех тестов нужно разрушить созданную среду? По техническим причинам (так уж работает библиотека
Test::Unitrunrequire '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Что должно входить в тест? Нужно как-то решить, прошел он или нет. Для этой цели применяются утверждения.
Простейшее утверждение — это метод
assertfalsenilЕсть и другие методы для формулирования утверждений. Обратите внимание, что «ожидаемое» значение всегда предшествует «фактическому».
assert_equal(expected, actual) # assert(expected==actual)assert_not_equal(expected, actual) # assert(expected!=actual)assert_match(regex, string) # assert(regex =~ string)
