我们可以有在godoc中出现但无法运行的示例，以及作为go test一部分运行的可运行示例。对于go test来说太慢或不可靠的示例，例如需要访问互联网的示例呢？我可以使它们无法运行，但如果用户想要尝试一下呢？go test -run ExampleSlow不起作用，下一个最佳选择是复制粘贴到主函数中，这很尴尬。
另一个选项，也就是我倾向于做的，是将示例作为其他地方的主要包。但这也很讨厌；如果示例包没有隐藏，go install ./...会包含它们，如果它们在另一个仓库或_examples中隐藏，它们就很难找到。
将示例隐藏在单独的目录/仓库中的另一个缺点是go test ./...不会检查它们是否编译良好；一个人必须记住也要检查那个目录/仓库。
为了获得一些背景信息，我试图将https://github.com/chromedp/examples折叠到主仓库中，从一个example_test.go文件开始。第二个和第三个示例很快，但第一个访问互联网且速度较慢。我不想用go test运行它，但我希望它出现在godoc中，并允许人们轻松地运行它以尝试一下。
我没有将其标记为提案，因为我没有具体的想法；这只是我尝试记录具有非平凡示例的包时遇到的问题描述。
/cc @acln0@mpvl@bcmills@ianlancetaylor
9条答案
按热度按时间uxh89sit1#
我想到的一个变化是添加一个测试标志，这样
go test就不会运行一个慢的例子，而像go test -slowexamples -run SlowExample这样的显式命令会运行。这可能是一个糟糕的解决方案，但它有助于说明我希望以某种方式获得的两个替代方案。编辑：稍微更好的标志是
go test -allexamples -run ExampleWithInternet。wtlkbnrh2#
你可能可以在那些慢速示例中添加一个//build:slowexamples标签，然后使用go test -tag slowexamples -run "ExampleSlow.*"运行它们。这会解决你的问题吗？
de90aj5v3#
不；将示例隐藏在构建标签后面与将它们隐藏在
_examples包中具有相同的问题。它们不会出现在godoc中，如果无法正确构建，go test ./...也不会报错。sr4lhrrt4#
对于
go test来说，太慢或不可靠的示例怎么办？例如，需要访问互联网的示例？之前关于#30595的讨论，尤其是#30595(评论)。
不幸的是，与测试不同，可运行的示例没有一个
Short方法来查询，也没有一个Skip方法可以在无法运行时中止示例。(它们要么有一个始终运行的Output行，要么缺少一个始终仅构建的Output行。)jmp7cifd5#
谢谢。我确实看到了那个帖子，并且同意Ian的回复。我认为这里的情况并不相同；测试和示例本质上是不同的东西。通常情况下，用户会对示例感兴趣，并希望查看和运行它们，无论它们是否符合“慢速”或“集成”示例的标准。
tvz2xvvm6#
我认为“see”和“run”之间有很大的区别。
我将提出以下观点：
go doc应该在文档中显示所有示例，无论它们的速度或要求如何。go test默认情况下应该只测试封闭的子集示例，让用户通过设置环境变量或构建标签来明确启用非封闭测试。go test -short应该只测试封闭且快速的子集示例。与
Short和Skip的联系是，我们目前没有办法将示例标记为“慢”，也无法检查仅应可运行但默认不运行的示例的编译情况。kzmpq1sx7#
你所说的大部分内容对我来说是有道理的。我唯一要补充的是，我并不关心示例的速度本身；我很少遇到需要大量资源或时间的示例。我应该用“非封闭性示例”而不是“慢示例”来命名这个问题。或者甚至可以称之为“非确定性示例”。
vatpfxk58#
我应该用"非封闭性示例"而不是"慢速示例"来命名这个问题。或者甚至可以称之为"非确定性示例"。
如果这是重点，那么这可能与#23799中的Russ的评论有关(评论)
只要默认结果仍然被缓存，将此标记为依赖于外部事物是可以接受的，然后我们还可以添加一个'重新运行所有依赖于外部事物的测试'作为明确的标志。不确定具体会是什么样子。
离开Go 1.13。
s6fujrry9#
好的，我已经根据初步讨论的结果，将这个问题重新命名为我认为更好的概括。