これで、どれか一つでもラベルにないとポリシーがひっかかる。ようにして使っている。必要に応じてヘルパーが増えていったりする。繰り返し試しながら書くことになる。ポリシー評価が意図通りか試す、試したものを戻す、といった余計は作業が多く発生する。このため、ポリシーは「想定するINPUTを用意」して、「INPUTに対してポリシーを記述」して、「ポリシーをテストで通るか確認」して、「実際のYAMLに対して実行」するという流れがうまく当てはまる。テストでは、次の3つを行う。用いる場合、テストは次の形式で実行できる。fullテストのテンプレテストは、「ポリシーファイル_test.rego」が定番なので従っておく。テストには注意が3つある。評価するポリシーと同じ出力になるようにしないといけない引数がないのは忘れがち。万が一引数があるとポリシーが正常に評価されてもテストは通らない。ポリシーで固定文字列なら同じものを入れればいい。使っている場合は、テストでも同じ結果になるように注意が必要だ。"推奨ラベルを付与してください。sprintf("推奨ラベルを付与してください。"推奨ラベルを付与してください。}}テストのサンプル例えばKubernetes推奨ラベルがあることを保証するポリシーがあるとしよう。sprintf("推奨ラベルを付与してください。input.metadata.name])}これに対して、labelsがないテストとあるテストを用意すれば、実際のYAMLで確認することなくポリシーが妥当かユニットテストできる。付けることで正常にとおったことをテストできる。"推奨ラベルを付与してください。"推奨ラベルを付与してください。付ける}テストが通らないときのデバッグデバッガで止まるわけじゃないので、2つ使って評価を試す。対してポリシーがちゃんとかかっているか試行錯誤するのが手っ取り早い。やってみるのは結構オススメ。プレイグラウンドでポリシーは当たったけど、どう評価されているか確認しながらやりたいだろう。