Webエンジニアの筆者「じょうげん」氏が、不具合修正のPR(プルリクエスト)を2つに分割する「Red-Green Stacked PR」という手法を提案しています。この名称は本記事のために自身で考案したとのことです。1つ目のPRでは不具合を再現するテストのみを追加し(test.fails修飾子を付与)、実装コードには手を付けません。このテストは現在のコードで落ちるため、CI(継続的インテグレーション)はGreenと判定されます。
2つ目のPRは1つ目のブランチをベースにスタックし、test.failsを外して実装を修正し、テストを通します。従来はレビュアーが手元でブランチをcheckoutし、修正コードをコメントアウトしてテストが落ちることを確認する手作業が必要でしたが、この手法ではRed(失敗)からGreen(成功)への遷移がCIの履歴として自動的に記録されます。
筆者自身、CIが保証するのは「テストが現在のコードで落ちる」ことまでで、「落ちる理由が対象の不具合そのものであること」までは保証しないという限界も明記しています。
出典が伝えている要点
- 著者は「Red-Green Stacked PR」という名称を本論執筆の便宜上、自身で考案したと述べている
- 提案手法は不具合修正PRを2つのスタックされたPRに分割するというもの
- 1つ目のPRでは、test.fails修飾子を付与して不具合を再現するテストのみを追加し、実装コードには手を付けない
- 1つ目のPRのテストは現在のコードで落ちるため、CIはGreenと判定される
- 2つ目のPRは1つ目のPRのブランチをbaseに指定する
- 2つ目のPRでは、test.failsを外して通常のtestに変更し、実装を修正してテストを通す
- 従来の不具合修正PRのレビューでは、ブランチをcheckoutして修正コードをコメントアウトし、テストを実行し、修正を戻すという手作業が必要だった
- Red-Green Stacked PR手法では、Red(失敗)からGreen(成功)への遷移がCI履歴として記録される
- 著者は、CIが保証するのは「このテストは現在のコードで落ちる」ところまでで、「落ちる理由が対象の不具合であること」までは保証しないと述べている
原文より
現在の実装に対して、このテストが期待通り落ちたということです。レビュアーが手元でやっていた3番目の手順が、そのままCIの記録になります。
出典: zenn.dev