共同オープンソースプロジェクトでTDDが実行可能か

多くの人にパッチなどを提出してもらいたいと思う/期待するオープンソースプロジェクトを開始したいとしましょう。厳密なTDDアプローチをとることは実行可能ですか？共同作業者がパッチを提出するたびに品質テストを作成することを期待/信頼できるか？

私が考えていた1つのことは、個々のバグレポートと機能リクエスト用のテストスイートを作成し、すべてのパッチ/プルリクエストがテストに合格することを要求しますが、その時点で機能/バグ修正を書く方が良いようです自分。

私が知る限り、TDDを使用する（または少なくともテストを書く）主要なオープンソースプロジェクトのほとんどは、個人またはチームによって純粋に記述されているようで、TDDなどのプラクティスを実施するのは簡単です。

open-source tdd collaboration

— DormoTheNord
ソース

あなたの研究を共有することは誰にとっても役立ちます。あなたが何を試みたのか、なぜあなたのニーズに合わなかったのか教えてください。これは、あなたが時間をかけて自分自身を助けようとしていること、明白な答えを繰り返すことから私たちを救うこと、そして何よりもあなたがより具体的で関連性のある答えを得るのを助けることを示しています。質問方法

— gnat

@gnat StackExchangeを検索しましたが、ユニットテストを使用したオープンソースプロジェクトの例を尋ねる質問がいくつかありましたが、これは私の質問とは異なります。ご要望に応じて、さらに情報を追加しました。

— DormoTheNord

DormoTheNord @gnatは具体的で引用された例を意味すると信じています。

— ハネフムバラク

「機能/バグ修正を自分で書くだけの方がいいでしょう。」テストの有無にかかわらず？あなたはTDDの支持者ですか、それともこのコンテキストで実行可能かどうかを確認していますか？

— ジェフ

もちろん、協力者がパッチを提出するたびに品質テストを作成することを期待できます/期待する必要があります。それは有益なだけでなく、今日の大規模なオープンソースプロジェクトでは非常に一般的です（ご希望であれば、例を挙げることができます）。

— ベンジャミングリュンバウム

回答:

パッチを一般大衆が提出できるオープンソースプロジェクトでは、TDD（テストファースト）アプローチを実際に実施することはできません。

何をすることができます強制することは、すべてのパッチが通過しなければならない、パッチでは、これらのテストケースという含まれている修正のためのテストケースのセットだけでなく、すべての既存のテストケースを持っていなければならないということです。プロジェクトのポリシーを使用して同意していることがわかっている少数の信頼できる開発者にのみコミット権を付与し、テストケースに合格した場合にのみ送信/プルリクエストが組み込まれることを公に述べることでこれを実施できます十分なカバレッジ）。

これは、テストが書かれていることを保証するものではありません。最初が、それはテストがされていることを確認しない書かれて。

— バートファンインゲンシェナウ
ソース

リポジトリの所有者は、プロジェクトの品質基準に適合しない変更をプルすることを拒否できますか？寄稿者がこれを嫌うと、おそらく寄稿の質と量に苦しむでしょうが、それを強制できないということではありません。確かに？

— トムW

@TomW：たとえば、実装が完了した後に作成されたテストではなく、TDDプラクティスに従って作成されたものであることをどのように確認しますか？

— バートヴァンインゲンシェナウ

ああ、私はあなたが何を意味するかわかります。ある程度の厳密さの損失は避けられないと思いますが、コードがテストに付属していること、テストが十分にきめ細かく、想定されるすべてをカバーしていることを確認できます。私はgitにそれほど詳しくはありませんが、特定のプルリクエストについて、そのチェンジセットのコミットシーケンスを調べて、開発者がそれを生成するための適切なプロセスに従っていることを確認することは可能ですか？

— トムW

つまり、自分の内部プロセスを確認することはできませんが、その出力が特定の基準を満たしていることを確認できます。テストを要求し、設計が論理的であることを確認することは、所有者の権限の範囲内です。

— エイドリアンシュナイダー

コードの作業を許可する前に、テスト専用のパッチを提出するように人々に依頼できます。これにより、コード自体が記述される前に、計画された設計をレビューする追加の機会が提供されます。

実際には、これは人々がプロジェクトに貢献することに対する熱意を殺す可能性があります-または、あなたの方法論に同意する人々に火を付けるかもしれません。

ただし、レビュー担当者は、開発を失速させないために、デザインレビューをすばやく回すことに非常に優れている必要があります。

— アレックス・ファインマン
ソース