В Java обычно создаются две исходные папки src и test с идентичной иерархией пакетов.
В Ruby вы просто помещаете все тесты в ту же папку, что и тестируемый класс? Или вы создаете подобную иерархию в отдельной папке? Если да, то как вы управляете require путями в модульных тестах?
Сначала каждый камень имеет типичное расположение. Код почти полностью находится в lib. В корневом каталоге есть только метаданные, такие как файл README, gemspec, и некоторые дополнительные данные конфигурации. Если вы пишете веб-приложение с чем-то вроде Rails или Sinatra, вместо этого используются их стандарты макета.
Однако во всех этих типах проектов тесты можно найти в аналогичных местах. В зависимости от того, какую среду тестирования вы используете, существуют разные стандарты.
Если вы используете Test::Unit или minitest, тесты обычно находятся в каталоге test. Нет никаких реальных стандартов того, как на самом деле организовать тестовые файлы в этом каталоге. Я лично счел полезным хотя бы частично отразить макет файла тестируемого кода. Если вы широко используете модули / пространства имен, это должно сделать его довольно читабельным при выполнении этой настройки и в ваших тестах.
Если вы используете RSpec, тесты (тогда называемые спецификациями) помещаются в каталог spec. Приведенные выше примечания относительно схемы реальных тестов применимы и здесь.
В конце концов, как настроить тесты, это в основном ваше личное решение. Поскольку тесты - это область, в которой многие люди имеют разные (и твердые) мнения, святого пути к успеху не существует. Вам следует взглянуть на некоторые драгоценные камни, которые вы используете, и на то, как они работают. Пример minitest макетов можно найти в гемах Rails, например для ActiveRecord. Примером тестов RSpec является моя библиотека rackstash.
spec_helper, содержащий зависимости в проектах rspec.
- person Garrett Hall; 23.11.2011
\lib и \test.
- person ashes999; 20.03.2014
Я тоже новичок в Ruby и задаюсь тем же вопросом. Часть, которую я не понял, заключалась в том, как организовать их иерархически, чтобы они соответствовали потенциально иерархической организации компонентов в каталоге lib, а затем запускать их все как пакет.
Я не так долго гуглил, но мои результаты уже хуже, чем ожидалось. Самое полезное, что я нашел, - это из ruby wiki:
Классы тестовых примеров могут быть собраны вместе в тестовые наборы, которые представляют собой файлы Ruby, для которых требуются другие тестовые примеры:
# File: ts_allTheTests.rb
require 'test / unit'
require 'testOne'
require 'testTwo'
require 'testThree'Таким образом можно естественным образом сгруппировать связанные тестовые примеры. Кроме того, наборы тестов могут содержать другие наборы тестов, что позволяет построить иерархию тестов.
Раньше я избегал подкаталогов в моем тестовом каталоге и делал что-то подобное в моем Rakefile или любом рубиновом файле, который фактически выполняет тесты:
$LOAD_PATH << File.dirname(__FILE__)
require 'test/unit'
Dir.glob('test/test_*', &method(:require))
Итак, если я объединю эти два метода, у меня будет файл для каждого каталога, который динамически требует тестов из этого каталога, которые, в свою очередь, потребуются файлом для родительского каталога. Но это, похоже, сводит на нет мои первоначальные попытки избежать скуки.
Затем я нашел несколько классы в ruby-doc, который звучал актуально, но недостаточно документирован. Однако похоже, что вверху будет больше информации для Test :: Unit, который я легко мог пропустить. Я еще не прочитал все это, но это выглядит многообещающе.
