gocheckを使用したテストの実行に問題があります。実行するテストを指定するには、フラグを渡す必要がありますgo test -gocheck.f ApiSuite.TestSomeFunction。
テスト ファイルは設定パッケージをインポートします。このパッケージにはinit()、独自のフラグと呼び出しを指定する関数がありますflag.parseFlags()。私が抱えている問題は、これが gocheck フラグをオーバーライドしているように見えるため、フラグ -gocheck.f が認識されないというエラーが発生することです。
注: これが関連しているかどうかはわかりませんが、一部のパッケージでのみ発生し、他のパッケージでは発生しません。パッケージをインポートすることを決定した順序に基づいているだけだと思いますが、これが関連する場合に備えて言及したいと思います。
他の誰かがこの問題に遭遇しましたか? 上書きせずにすべてのフラグを組み合わせる簡単な方法、またはカスタム フラグよりも gocheck フラグを優先させる簡単な方法はありますか?
他のパッケージが他のフラグを定義していることを気にせずに複数のパッケージが flag.Parse を呼び出す場合は、問題が発生します (既に経験したように)。「フラグ」パッケージの状態はグローバルな状態であるため、初期化中に異なるパッケージが競合してグローバル変数の値を異なる値に設定する場合とほぼ同じです。明らかに、それはうまく終わらないかもしれません。
これを防ぐ簡単な方法flag.Parseは、(最初の概算で) 1 回だけ呼び出す必要があることです。そのため、通常は "main" パッケージでのみ表示されます。メイン以外のパッケージが呼び出す場合、通常、パッケージ「メイン」で呼び出されたflag.Parseものと競合します。パッケージをテストするためにを合成し、その合成された「メイン」パッケージから呼び出されることにflag.Parse注意してください。go testpackage mainflag.Parse
一方、メイン以外のパッケージでのみフラグを定義しflag.Parse、パッケージ「メイン」で呼び出されることに依存する方が「安全」です（ただし、競合はとにかく可能です）。非メイン パッケージでは、flag.Parsed()flag.Parseを使用して呼び出されたことを確認できます。
上記は簡略化して書いています。追加のオプションについては、パッケージ フラグのドキュメントを確認してください。一部のシナリオでは、たとえばflag.Flagsetを使用することにより、つまりパッケージ内のフラグ オプションにローカル状態を使用することにより、より多くの「パワー」を取得できます。
ただし、個人的には、パッケージ「main」の外部でパッケージ「flag」を使用せず、API を介して構成可能なパッケージの動作を設定することを好みます。ただし、*_test ファイルやその他の特殊なケースなどには例外があります。