Add WorkerPool test #40
Conversation
| } | ||
| } | ||
|
|
||
| func TestWorkerPoolMultiDB(t *testing.T) { |
There was a problem hiding this comment.
今は正しく動いててよさそうなんですが、手を加えていく際のテストに対する信頼性の観点で以下コメントです↓
これ Worker は引数 Job の Queue フィールドの値をそのままインサートするので、「期待通りのキューと対応するワーカーが動作した」ことを示すテストにはなってないかも、と思いました。具体的には、今の場合、もし実は pool1 しか動作してなかったとしても、気づけなさそうです。
以下のどちらかをテスト設計に組み込むとより良いかもと思いました
- WorkerPool ごとに sync.WaitGroup を分ける (意図せず片方の pool が動作していない場合、 wg.Done しないので気付ける)
- 各 WorkFunc は引数Jobの Queue をそのまま job_test にインサートしない (意図せず片方の pool が動作していない場合、 job_test の queue の内容が期待と異なるので気付ける)
There was a problem hiding this comment.
具体的には、今の場合、もし実は pool1 しか動作してなかったとしても、気づけなさそうです。
pool1しか動作していなかった場合、SELECT name, queue FROM job_test の結果が期待する結果と異なるので気付くかなと思ったのですが、いかがでしょうか？
There was a problem hiding this comment.
たとえば WorkerPool が que_jobs からジョブを取得する際に queue を無視するバグを仕込んだ場合 (where 句に queue 絞るのを忘れるとかで...) に全部のジョブを pool1 が取得する可能性ができることになり、それを pool1 が queue=queue2 で job_test にインサートするため気付けない... と言ったケースを想定しました。
が、SQLの取得周りは別のレイヤのテストで動作保証するのであればここでは気にすることではないかもしれません...
There was a problem hiding this comment.
各 WorkFunc は引数Jobの Queue をそのまま job_test にインサートしない (意図せず片方の pool が動作していない場合、 job_test の queue の内容が期待と異なるので気付ける)
あ、こちらは修正しようかと思います
|
🙏 |
WorkerPoolのテストを追加します。