Golang冲突的命令行标志

Question

我在使用gocheck运行测试时遇到了麻烦。我需要向其传递一个标志，以指定要运行的测试，例如go test -gocheck.f ApiSuite.TestSomeFunction。我的测试文件导入了一个设置包，其中有一个init()函数指定其自己的标志和调用flag.parseFlags()。我遇到的问题是，这似乎覆盖了gocheck标志，因此我得到一个错误，即无法识别-gocheck.f标志。注意：不确定这是否相关，但是仅在我的某些软件包中发生，而在其他软件包中则没有。我认为这只是基于go决定导入软件包的顺序，但是我想我会提到它，以防相关。还有其他人遇到这个问题吗？是否有一种简单的方法就可以使所有标志组合在一起而不会造成混乱，或者使gocheck标志优先于我的自定义标志？

Answer 1

如果有多个程序包调用flag.Parse，而不必担心其他程序包定义了其他标志，那么您就很麻烦（就像您已经体验到的那样）。“标志”包的状态是全局状态，因此它几乎相同，就好像不同的包将在初始化期间竞争将全局变量的值设置为不同的值一样。显然，这可能不会很好地结束。

防止这种情况的简单方法：flag.Parse应该只调用一次（在第一次近似中）。这就是通常只在软件包“ main”中看到它的原因。如果您的非主程序包调用，flag.Parse则通常会与flag.Parse“主”程序包中的任何调用冲突。注意，go test合成一个package main以便测试包和flag.Parse 被从该合成“主”包调用。

另一方面，仅在非主程序包中定义标志并依靠flag.Parse其在程序包“主程序”中进行调用会更“安全”（但仍然可能发生冲突）。在非主程序包中，然后可以flag.Parse使用flag.Parsed（）验证已被调用。

上面写的是简化的。有关其他选项，请查看包装标志文档。在某些情况下，例如，可以使用flag.Flagset获得更多的“力量” ，即，通过对包中的标志选项使用本地状态。

但是，我个人不希望以任何方式在包“ main”之外使用包“ flag”，而是通过其API设置任何可配置的包行为。但是，确实存在例外，例如在* _test文件或其他特殊情况下。