Как протестировать программу командной строки Ruby с помощью Cucumber, которая выводит огромное количество данных?

Короткий ответ: вы не должны этого делать.

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

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

Then the exit status should not be 0

Это предполагает, что сценарий следует стандартному соглашению о том, что ненулевой статус выхода сигнализирует об ошибке.

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

Then it should fail with
"""
Some error message
"""

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

Редактировать: вы изменили свой пример, чтобы он тестировал успешно, а не неудачно, но мой основной совет остается прежним:

1. Отделяйте специфику вывода от логики сценария. Используя пример в комментариях, если у вас есть тест, который подтверждает, что вы можете вывести один пользовательский комментарий, и другой тест, который подтверждает, что вы вывели правильные 100 комментариев, то этого достаточно, вы не нужно иметь вывод на 100 комментариев в сценарии Cucumber.
2. Пишите сценарии Cucumber с точки зрения пользователя. Каждый сценарий должен тестировать что-то важное для пользователя. Старайтесь свести их к минимуму, удаляя все, что просачивается из реализации, когда пользователю все равно.
3. Для этого используйте встроенные конструкции Aruba, которые проверяют частичные совпадения. Ищите ключевые слова или фразы в выводе. Мало того, что тесты Cucumber будут легче читать, они будут более надежными и невосприимчивыми к несвязанным изменениям вывода.

Для тестирования вашей программы у вас есть 2 варианта:

1. Проверяйте только соответствующую часть сообщения (то, что вы действительно хотите проверить с помощью этого теста). В Aruba есть встроенный stepdef. так что это очень легко

2. Проверьте полное сообщение. Если сообщение короткое, вы можете использовать встроенную функцию Aruba. шаг определения. Однако, если сообщение длинное, вы можете поместить его в отдельный файл. Так как Aruba не содержит такого метода, вы должны написать этот stepdef самостоятельно.

Это может выглядеть так:

# Require aruba/api before that
Then /^it should (pass|fail) with message from file "(.*)"$/ do |pass_fail, filename|
  exact_output = File.read(filename)
  Aruba::API::assert_exit_status_and_output(pass_fail == "pass", exact_output, true)
end

Если вы хотите написать много тестов и много похожих сообщений, у вас может получиться много WET. Утверждение полного сообщения усложнит вспомогательные тесты в случае изменений.

Таким образом, вы можете захотеть использовать какой-то механизм шаблонов для подтверждения этих сообщений, чтобы сделать тесты DRYer.

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

Таким образом, существует компромисс между этими двумя вариантами. Обычно вы строите одни тесты по методу 1, другие по методу 2. Вы должны подумать, что будет лучше в вашем случае. Я не знаю никакого золотого правила.

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

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

1. Напишите конкретную функцию, охватывающую одну тему, только в .feature файле. Хотя я знаю, что вы упомянули When I run my program для демонстрационных целей, такая широкая тема неприемлема.

2. Поместите .feature файлов в папку features/. И, при необходимости, дополнительно разбить их на подпапки типа features/user/user_login.feature.

3. Используйте Scenario Outline и Examples для организации похожих выходных данных в одном сценарии. Примеры будут иметь ряды для четкого представления каждого из них.

Надеюсь, это поможет.

Я бы рекомендовал следующее:

When I run `my_app`
Then the exit status should not be 0
And the output should contain:
"""
some output
"""

Таким образом, пока из вашей программы выводится «некоторый вывод», тест проходит успешно, но дополнительный вывод игнорируется, и вашему тесту не требуется весь этот вывод.

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