TDDとバージョン管理
私は現在TDDについて学び、それを私の個人的なプロジェクトで実践しようとしています。また、これらのプロジェクトの多くでバージョン管理を幅広く使用しています。特にコミットを小さく保つという格言に関しては、典型的なワークフローにおけるこれら2つのツールの相互作用に興味があります。頭に浮かぶいくつかの例を次に示します。
新しいプロジェクトを開始して、まだ存在しないクラスを作成するための簡単なテストを作成します。テストがコンパイルされていなくても、クラスを書き込む前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブ化する必要がありますか？
バグを見つけ、それを再現するためのテストを作成します。失敗したテストをコミットするか、バグ修正を実装してコミットする必要がありますか？
これらはすぐに頭に浮かぶ2つの例です。回答に追加の例を提供してください。
編集：
どちらの例でも、テストを書いた直後にテストに合格するためのコードを書くと仮定しました。別の状況も発生する可能性があります。私はコミットせずにTDDを使用してプロジェクトに数時間取り組んでいます。最終的にコミットするとき、自分の作業を小さなチャンクに分割したいと思います。 （Gitを使用すると、1つのファイルの変更の一部のみをコミットしたい場合でも、これは比較的簡単です。
これは、私の質問がwhatと同じくらいwhenコミットします。
テストがコンパイルされていなくても、クラスを書き込む前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブ化する必要がありますか？
もちろん違います。テストとクラスの両方を完了する必要があります。何かをコミットする1 コンパイルさえできないのは意味がありませんし、同じプロジェクトを定期的に行うと、同じプロジェクトで作業している人は間違いなく怒ります。
バグを見つけ、それを再現するためのテストを作成します。失敗したテストをコミットするか、バグ修正を実装してコミットする必要がありますか？
いいえ、失敗したテストをコミットしません。 ルブランの法則 状態：
後で決して等しくない。
テストが長時間失敗する可能性があります。問題が検出されたらすぐに修正することをお勧めします。
また、 TDD開発スタイル は、
テスト駆動開発では、失敗したテストケースの追加、テストケースの合格、リファクタリングのステップを常に繰り返します。
失敗したテストをチェックインすると、サイクルが完了しなかったことを意味します。
1 私がコミットと言ったとき、私は本当にトランクにコミットすることを意味しました（gitユーザーの場合、他の開発者が変更を取得できるように、変更をプッシュしてください）。
テストがコンパイルされていなくても、クラスを書き込む前にテストをコミットする必要がありますか？
番号。
失敗したテストをコミットする必要がありますか
番号。
ここでは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の観点から、「最初にテストをチェックインしますか？」という質問。作業しているコードに完全に依存しています。新しいコードの場合は、チェックインする価値のあるものがなくなるまで、何もチェックインしません。しかし、それがすでにコンパイルまたは出荷されたコードで見つかったバグである場合は、バグを再現するためにテストをチェックインして、ITSELFでチェックインする価値があります。特に、それが就業日の終わりであり、修正する前にオフィスを離れる場合コード。
（もちろん、ショップでユニットテストが失敗した場合に終了する自動ビルドプロセスがある場合、バグを修正するまで失敗したテストをチェックインしたくないかもしれません。しかし、これは奇妙な方法のように見えます。および「バグの文書化」と「バグの修正」は、2つのまったく異なるチームで行うことができます。）