如何测试推送宝石的脚本？

Question

我有这个脚本：

#!/usr/bin/env ruby
# frozen_string_literal: true

if ARGV.any?
  puts "USAGE: release"
  exit
end

def system!(command)
  puts command
  system(command, exception: true)
end

File.delete(*Dir["*.gem"])
system!("gem build")
system!("gem push *.gem")
File.delete(*Dir["*.gem"])

我简单地称之为

release

（它是 dorian-release gem 的一部分）。

我正在尝试测试它，但不确定如何最好地做到这一点，chatgpt 建议存根，但这并没有真正测试任何东西。

我想模拟对 rubygems 的 HTTP 请求，但不确定如何执行它，因为它是子命令。

有什么想法吗？

Answer 1

不要在应用程序规范中测试内部依赖关系

我想模拟对 rubygems 的 HTTP 请求，但不确定如何执行它，因为它是子命令。

不，不，不！虽然执行某种集成测试以确保您的应用程序已完成一些预期的系统更改可能是有效的，但单元、功能和集成测试不应该测试其他库的内部结构。您需要在这里重新考虑您的目标。 作为一个更清晰的例子，除非您正在研究解释器内部，否则您永远不应该测试 Kernel#puts 的工作原理，尽管您可能

偶尔

找到一个用例来验证 $stdout 或 $stderr 指向哪里您期望的，甚至发送到流的输出包含您期望的正确插值输出。测试 Kernel#puts 本身是否works永远不应该成为测试的焦点。 同样，确保

gem push

将您的 gem 推送到 RubyGems 或测试服务器不需要任何复杂的东西。除非您深入调试，否则您“真正”需要知道的是 gem 是否已发布。如果您不信任

gem push

返回正确的退出状态或引发异常 — 您可能应该这样做，因为这是 Ruby 生态系统中广泛使用的一部分，并且看起来它更像是用于验证防火墙规则的代理测试或类似的东西 - 那么你应该检查服务器以查看新的 gem 版本是否已发布。您可以通过多种不同的方式来完成此操作，具体取决于您实际需要的复杂程度。我会尽可能保持简单，因为否则你就会陷入测试测试依赖项的兔子洞，这是受虐狂并且通常是不必要的。按从简单到复杂的顺序：

测试您要发布的本地宝石的通配符是否正确。

1. 确保您的

   glob

   仅返回有效值，并正确处理无效值。
   • 确保当文件列表为空、nil 或包含其他无效值时，应用程序 执行正确的操作。
   依赖 RubyGems 的退出状态或异常。

2. 根据您的预期检查

   gem list -r #{gem_name}
的输出。

3. 使用
   OpenURI 模块
从 RubyGems 服务器获取网页内容，并 grep 获取您期望的版本号。

4. 使用 Nokogiri 解析 RubyGems 网页并使用

   Gem::Version
比较语义版本。

5. 使用

   RubyGems Web Server API
中的
6. gem 方法

   查询有关已发布 gem 的详细信息。 跟踪 RubyGems HTTP(S) 调用的内部结构通常不应该做，除非您是 RubyGems 开发人员。对于其他人来说，如果您比运行测试代理更深入地了解“为什么”您的 HTTP(S) 调用在网络或协议级别失败，那么您就会产生不必要的开销。在应用程序层测试应用程序，如果您依赖常见的外部库，请信任

   他们的
测试来验证它们是否按预期工作！