Code Formatting

コード品質、フォーマット、規約

コードのフォーマットとリンティング

• Go コードを記述した後、make lint-fix を使用してリンティングの問題の大半を自動修正します
• コミットする前に、make verify を実行してリンティングとテストの両方が通ることを確認します
• Markdown ファイルには、make verify-codespell を使用してスペルミスを検出します

テスト規約 - 必須

テストの命名

絶対に守るべきルール：すべての Go テスト名は、必ず次の形式に従う必要があります。

name: "When <condition>, it should <expected behavior>"

例：

name: "When NodePool has valid image ID, it should create Azure machine template"
name: "When subnet ID is invalid, it should return error"
name: "When encryption is enabled, it should configure disk encryption set"

次のような汎用的な名前は絶対に使用しないでください。

• ❌ 「管理対象 ID を持たない標準ケース」
• ❌ 「ImageID を使った基本的な Azure マシンテンプレート」
• ❌ 「エラーケース - 無効なサブネット ID」

必ず「When...it should...」形式を使用してください。

• ✅ 「NodePool に管理対象 ID がない場合、ID を含まないテンプレートを作成する」
• ✅ 「NodePool に ImageID がある場合、基本的な Azure マシンテンプレートを作成する」
• ✅ 「サブネット ID が無効な場合、サブネットの解析メッセージを含むエラーを返す」

単体テスト関数の命名

単体テスト関数には、テスト対象の関数名を付け、標準的な Go の Test<FunctionName> 規約に従う必要があります。

// Testing function ReconcileNodePool
func TestReconcileNodePool(t *testing.T) { ... }

// Testing function buildAzureMachineTemplate
func TestBuildAzureMachineTemplate(t *testing.T) { ... }

次のような汎用的、またはテスト対象と無関係な関数名は絶対に使用しないでください。

• ❌ TestNodePoolFeatures
• ❌ TestAzureIntegration
• ❌ TestVariousCases

各テスト関数は、テスト対象の関数と 1 対 1 で対応させてください。関数が複雑で多くのテストケースが必要な場合は、単一の Test<FunctionName> 関数内でテーブル駆動テストを使用し、各ケースには「When...it should...」形式の名前を付けてください。

単体テストの配置

• 新しい関数を作成したり、既存の関数を変更したりする場合は、必ず単体テストを追加してください
• 単体テストは、テスト対象のコードの隣に配置してください — 同じパッケージディレクトリ内の _test.go ファイルに配置します
• 新しいテストを test/integration/ に配置しないでください — これはレガシーディレクトリです。新しい単体テストはテスト対象のコードと同じ場所に配置します。クラスターが必要な新しい統合形式のテストは、test/e2e/ または test/envtest/ を使用してください

クイックチェックリスト

コミットする前に：

• Go コードに対して make lint-fix を実行した
• make verify を実行した（成功）
• テスト名が「When...it should...」形式になっている
• 新しい関数に単体テストがある
• Markdown を make verify-codespell でチェックした