使用test-unit，你最终会得到这样的代码：

class TestScript < Test::Unit::TestCase
  def test_output
    assert_equal 'test', `script --options`
  end
end

字符串
在处理程序的输出时，你可能会想使用open3库，因为它可以让你更好地控制如何处理它。你也可以为它编写自己的 Package 器，比如assert_output_equal：

def assert_output_equal(output, command, message = nil, &block)
  Open3.popen3(command) do |stdin, stdout, stderr, wait_thr|
    assert_equal output, stdout.read, message, &block
  end
end

型
您可以在此基础上进行添加，以测试流程的状态，确保它成功，并且在STDERR上没有任何输出等。
当测试产生大量文本输出的东西（例如JSON数据，格式化列表）时，我发现最好在test/expect这样的地方创建文件，并将文件与输出进行比较，而不是在源代码中定义文本。这使得创建文件变得容易：

old_script > test/expected/old_script.default
old_script --option > test/expected/old_script.with-option

型
它还使您的版本控制差异更容易阅读时，需要调整的东西在那里。

定义测试夹具

测试整个脚本的最佳方法是什么？我想测试脚本是否返回（打印）正确的结果。
你需要一个 test fixture，它包括一个已知的输入值和一个预期的结果。换句话说：
1.给定已知的输入值，
1.在运行程序时
1.然后，您将收到您的 * 预期 * 答案作为输出。
请注意，用这种方法测试整个程序可以告诉你是否从一组输入中得到了正确的结果，但它通常不会提供问题所在的洞察力。然而，许多形式的验收测试都使用这种“黑盒”方法进行测试，所以只要你了解其局限性，它肯定是一种合理的方法。

可能的框架

可能的测试框架列表不是无限的，但是如果你不想从头开始编写你自己的测试工具，你可能想尝试一个更流行的测试框架。一些可能的方法来开始你自己的研究包括：

• Bats
• Cucumber的
• Aruba的

当然还有很多其他的，但是根据你最初的问题，如果你想测试整个脚本而不是它的组件部分，你可能会想专注于ATDD或BDD测试工具，而不是单元测试。