TDDとバージョン管理

現在、TDDについて学び、個人プロジェクトでTDDを実践しようとしています。また、これらのプロジェクトの多くでバージョン管理を広範囲に使用しました。私は、特にコミットを小さく保つという格言に関しては、典型的なワークフローにおけるこれら2つのツールの相互作用に興味があります。ここに思い浮かぶいくつかの例があります：

1. 新しいプロジェクトを開始し、まだ存在しないクラスを作成する簡単なテストを作成します。テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか？

2. バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか？

これらは、すぐに思い浮かぶ2つの例です。回答に追加の例を提供してください。

編集：

両方の例で、テストを書いた直後にテストをパスするコードを書くと仮定しました。別の状況も発生する可能性があります。私は、コミットせずに数時間TDDを使用してプロジェクトに取り組んでいます。最終的にコミットするとき、作業を小さなチャンクに分割します。（Gitは、1つのファイルの一部の変更のみをコミットしたい場合でも、これを比較的簡単にします。）

これは、私の質問は、いつコミットするかということと同じくらいコミットすることに関することを意味します。

テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか？

もちろん違います。テストとクラスの両方を終了する必要があります。コンパイルすらしない何か¹をコミットしても意味がありませんし、同じプロジェクトで作業している人が定期的にそれを行うと怒りを覚えます。

バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか？

いいえ、失敗したテストをコミットしないでください。ルブランの法則は次のように述べています。

後で等しくなりません。

テストが長時間失敗する可能性があります。問題が検出されたらすぐに修正することをお勧めします。

また、TDD開発スタイルは次のことを示しています。

テスト駆動開発では、失敗したテストケースの追加、合格、リファクタリングの手順が常に繰り返されます。

失敗したテストをチェックインする場合、サイクルを完了していません。

¹コミットと言ったとき、本当にトランクにコミットすることを意味しました（gitユーザーの場合、変更をプッシュして、他の開発者がそれらを取得できるようにします）。

テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？

いや

失敗したテストをコミットする必要があります

いや

ここで2つのパラダイムについて話しています。

1. テスト駆動開発-コードのコミットについては何も言いません。確かに、コードの書き方と完了時期について説明しています。したがって、すべての「完了」をコミットの候補と見なします。
2. アジャイル開発、具体的には：「早期かつ頻繁にコミットする」（TDDを必要としない）。その背後にある考え方は、システム内の他のコンポーネントと早期に統合し、それによって早期のフィードバックを得ることです。DVCSをローカルでコミットし、プッシュしない場合、その意味では意味がありません。ローカルコミットは、開発者が作業を構造化するのにのみ役立ちます。

私の推奨事項は、コードがコンパイルされ、テストがグリーンになり、システムに貢献するものが得られるまで、TDDの輪をたどることです。したがって、機能を垂直にカットする必要があります。たとえば、新しいUIマスクでは、フォーム全体を作成してビジネスロジックなしでコミットするのではなく、1つの小さな側面を実装します。 。

大きなバグ修正の場合、バグがまだ修正されていない場合でも、改善（リファクタリングなど）のたびにコミットします。ただし、テストは緑色で、コードはコンパイルする必要があります。

確かに、gitのような健全なソース管理を使用することから始めます。

その後、好きなように作業し、各コーナーでコミットすることができます-任意のステップまたはサブステップは公正なゲームです。

次に、作業をプッシュする前に、作業全体を1つのコミットにまとめます。または、すべてが緑色で構成が意味をなすポイントでのカップル。そして、これらの賢明なコミットをプッシュします。複数の場合、--no-ffでマージするブランチにします。

ソース管理は、作業追跡システムや歴史家ではありません。コミットは合理的なコヒーレントデルタを提供するものとし、チェックアウト状態は少なくともコンパイルするものとします。中間体は、レビューのためにしばらく保持される場合がありますが、すべてが正常であると見なされると、機能ごとに1回のコミットが公平になります。

私が世界を理解することは、戻ることが望ましいかもしれない点をマークすることを約束することです。テストが失敗する（しかしコンパイルされる）ポイントは、間違いなくそのようなポイントの1つです。テストに合格しようとして間違った方向に歩き回った場合、コードを開始点に戻して再試行できるようにしたいと思います。コミットしていないとこれはできません。

テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？

分岐SCM（Gitを使用していることを確認しました）では、バックアップポイントが必要なとき（「何かを台無しにしました。作業ディレクトリを最後のバックアップポイントにリセットします」）または安定バージョンがあるときにコミットする必要があります。安定したバージョンがある場合（すべてのテストに合格）、現在の機能ブランチをメインの開発ブランチにマージすることも検討する必要があります。

または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか？

あなた次第です（gitは、チームの他のメンバーに影響を与えることなく、いつでもコミットできる柔軟性、またはさまざまな機能に取り組む能力を提供します）。同じブランチに複数の不完全な（機能しない）機能が同時にないようにしてください（それらは互いにブロックします）。

バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか？

テストコードが非常に小さく/書くのが簡単でない限り、私は通常そのために2つのコミットを行います。

これらは、すぐに思い浮かぶ2つの例です。回答に追加の例を提供してください。

編集：

両方の例で、テストを書いた直後にテストをパスするコードを書くと仮定しました。

それは間違った仮定かもしれません。単独で作業する場合（個人的なプロジェクト）、何もあなたが常にそれを行うことを止めません。私の最も成功したプロジェクトの1つ（プロジェクトの開発全体で高いコード品質とTDDを維持することに関して）では、テストを実装する数週間前に定義しました（つまり、「test_FOO_with_null_first_parameter」テストは空の関数として定義され、その後、モジュールのテストカバレッジを増やすために、1か月程度後にスプリント（またはスプリントの半分）を取得します。

別の状況も発生する可能性があります。私は、コミットせずに数時間TDDを使用してプロジェクトに取り組んでいます。最終的にコミットするとき、作業を小さなチャンクに分割します。（Gitは、単一のファイルの一部の変更のみをコミットしたい場合でも、これを比較的簡単にします。）これは、私の質問は、コミットするときと同じくらいコミットすることに関することを意味します。

バックアップポイントの作成に間違いなくコミットすると思います。これは、探索的テスト（「コードベース全体にいくつかのプリントを追加し、実行git reset --hardしたら実行して削除します」）とプロトタイピングに非常に適しています。

私のワークフローでは、可能な限り個人のソース管理ブランチで不確実な作業を行います。だから私は試して、失敗し、必要な場合はそれが機能するまで再試行し、実際の作業コードがある場合にのみより大きなプロジェクトにコミットすることができます。

TDDの観点から、「最初にテストをチェックインしますか？」という質問 作業しているコードに完全に依存しています。新しいコードの場合、チェックインする価値があるものが見つかるまで何もチェックインしません。ただし、既にコンパイル済みまたは出荷済みのコードで見つかったバグの場合は、バグを再現するためのテストをチェックインすることをお勧めします。BYITSELFはチェックインする価値があります。コード。

（もちろん、ユニットテストが失敗すると死ぬ自動ビルドプロセスがショップにある場合、バグを修正するまで失敗したテストをチェックインしたくないかもしれません。しかし、それは奇妙な作業のように思えます。バグの記録」と「バグの修正」は、まったく異なる2つのチームで行うことができます。）